On Mon, 27 Jun 2016 16:36:53 +0200 Martin Vidner <mvidner@suse.cz> wrote:
I am quoting the markdown here:
# YaST2 reorganization
1) Namespacing
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?
yes
* Use `Y2Users`, `Y2Storage`, etc. as namespace for each module to avoid collisions. Code should be organized under: * `Y2Users::Dialogs::SomeName` * `Y2Users::Clients::SomeName` * `Y2Users::Widgets::SomeName` * and so on * Avoid `UI` namespace as it sounds too 'general' (use `Dialogs` or `Widgets`).
* 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: Before: Yast.import "Arch" # -> /usr/share/YaST2/modules/Arch.rb After 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?
* Requiring YaST2 common code: * `yast/some-name` -> legacy or Ruby bindings code
So what exactly would be the namespaces+paths for a legacy - module - include - client ?
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, `Y2Users::*::SomeName`
no, it is not classes, but namespace ( a.k.a ruby modules ). module A module B class C ... is fine as it is just namespaced class module A class B .... class C ... 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 that class
* Avoid cases like the storage `Proposal` code when possible.
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. Josef