On Tue, 28 Jun 2016 12:01:05 +0200 Martin Vidner <[email protected]> wrote:
> On Tue, Jun 28, 2016 at 08:11:36AM +0200, Josef Reidinger wrote: > > On Mon, 27 Jun 2016 16:36:53 +0200 > > Martin Vidner <[email protected]> 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. I think we should start with agile approach and try it for few modules and if it works without issues, use it everywhere. > > > > > > > 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 ? the first one. yast2 is reserver for yast-yast2. We simply find better to have module separated namespaces, so there is no risk of collisions and Yast2::Y2Users::Dialogs::SomeName is too long to my taste, it almost fits whole line even if used without parameters. > > (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`. Well, ancor object it, so I expect we are probably too affected by YCP and he is ruby newcomer, so easier for him to see suspicious things. But if there is agreement, then as I mentioned before, it is not problem for me to change yast to modify require ( also note that it always have to be require "yast" and then require modules with require "yast/arch" > > 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. in ruby world singleton instances looks like one with Singleton mixin, so it have instance method ;) > --- > > > > > > > * 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"` ugh, why? I do not get what is wrong with keeping modules, includes and clients in Yast namespace? why it prevents gem packaging? and why it is incompatible? or do you mean to move them to lib directory under yast dir? But how to handle if some modules have Bootloader as client, module and also include? > > > 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 still do not get it.
pgpH3PkjSaiQ5.pgp
Description: OpenPGP digital signature
