Mailinglist Archive: yast-devel (48 mails)

< Previous Next >
Re: [yast-devel] YaST2 reorganization discussion
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 )

File organization should be a straightforward application of the
Ruby conventions to the namespacing, right?


* 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

* 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:
Yast.import "Arch" # -> /usr/share/YaST2/modules/Arch.rb
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,

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.


< Previous Next >
Follow Ups