On Tue, Jun 28, 2016 at 08:11:36AM +0200, Josef Reidinger wrote:
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 )
OK. The risk is a halfway change and even more confusion unless rules are documented clearly and enforced well. An alternative is to prepare and execute a big bang like we did with YCP->Ruby.
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
So according to the rule "yast2 for new code below(*), will it be Y2Users::Dialogs::SomeName in lib/y2_users/dialogs/some_name.rb or Yast2::Y2Users::Dialogs::SomeName in lib/yast2/y2_users/dialogs/some_name.rb ? (for reference, $ ruby -r active_support/core_ext/string/conversions -e 'puts "Y2Users".underscore' y2_users )
* 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?
That is not a sufficient reason to prefer `Yast.import` over `require`. To summarize what is weird about yast module, to an unsuspecting Ruby developer: --- Before: Yast.import "Arch" puts "system z" if Yast::Arch.s390 After: require "yast/arch" puts "system z" if Yast::Arch.s390 Classes in the Yast:: namespace (do not confuse with Yast2:: (?)) are all named with a ...Class suffix and have Yast::Module as a superclass. What looks like class methods all over the place are in fact instance methods on global singleton instances of these classes: class Yast::ArchClass < Yast::Module def s390 end end Yast::Arch = Yast::ArchClass.new This is because YCP, the previous implementation language of YaST, only supported a single instance of a module. ---
* 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.
IMHO wrong: - prevents gem packaging - incompatible with `require "yast/arch"`
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.
(*) see above
* `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 ). [...]
OK, I see.
* 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.
OK -- Martin Vidner, YaST Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu