Mailinglist Archive: yast-devel (48 mails)

< Previous Next >
Re: [yast-devel] YaST2 reorganization discussion
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@xxxxxxx> 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
< Previous Next >
Follow Ups