On Mon, 27 Jun 2016 16:36:53 +0200
Martin Vidner <mvidner(a)suse.cz> wrote:
I am quoting the markdown here:
# YaST2 reorganization
we write proposal below for namespacing
2) Migration from the current state
we agreed we would like to start with our target state and then move
files when it is touched or when new ones will be written, so no big
bang as even path is part of API ( you require it )
File organization should be a straightforward application of the
Ruby conventions to the namespacing, right?
* Use `Y2Users`, `Y2Storage`, etc. as namespace
for each module to
avoid collisions. Code should be organized under:
* and so on
* Avoid `UI` namespace as it sounds too 'general' (use `Dialogs` or
* Write a layer so, when requiring a library, it tries to find the
constant and, if it's not found, ask the component system. The
goal is to finally avoid `Yast.import`.
So for Arch, for example:
Yast.import "Arch" # -> /usr/share/YaST2/modules/Arch.rb
require "yast/arch" # -> .../lib/yast/arch.rb
# and ruby-bindings are adapted so that Perl
# can still find it with Import
yes, if we agreed we want it. Drawback is that actually modules are not
so common ruby classes, so it can also cause some confusion, so maybe
import is better to emphasis is not common ruby code in common location?
YaST2 common code:
* `yast/some-name` -> legacy or Ruby bindings code
So what exactly would be the namespaces+paths for a legacy
still same Yast as before, no changes there. We just agreed that for
code in lib, we prefer to not use Yast namespace, as there is
collisions with ruby. So we use different namespace.
* `yast2/some-name` -> new code
* Nested classes:
* Only for private APIs.
What does this mean? Above I see 3 nested classes,
no, it is not classes, but namespace ( a.k.a ruby modules ).
is fine as it is just namespaced class
is nested class C and C should be only private for B usage. You can
force to be it really private with Module#private_constant applied on
* Avoid cases like the storage `Proposal` code
Sorry, I don't know this case. What is it and why is it bad?
Well, basically what was wrong is that proposal have nested classes ( I
do not use inner class as it have slightly different behavior like
sharing context, which is not possible in ruby ).
And problem is that part of nested classes is for private usage only
and part is for public usage like ProposalConfiguration should be used
publicly and SpaceCalcular is private class only intended to use for
Proposal class. So it create confusion what is public class and what is
private class. So we agreed on this simple rule, that nested classes
are always private and is not part of public API.