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.
> >
> > 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
signature.asc
Description: Digital signature
