On Thu, 01 Aug 2013 11:03:33 +0200
David Majda
Dne 1.8.2013 09:53, Josef Reidinger napsal(a):
1) for skeleton I think that skeleton should be as small as possible, so move all repeating code to own method provided by a module (that is nice feature of rails, you can start really quickly ). And I think we should make clear difference between leaf module and module that can be reused by other modules. Because often there are Yast modules that have modules, but they use it themself exclusivelly. For such case now should be "lib" directory where is private Yast module code such us specific configuration logic or module specific dialogs. Advantage of such step is that you need not care about backward compatibility, as there is no public API and we can use all ruby features.
2) When module need to provide API for other modules ( so API should be based on requirements from other modules ) it should follow simple ruby - "Tell, don't ask" [1]. That helps with reducing of data leaks often seen in Yast ( when you change a map structure, you have problem because some modules depends on exact map structure ). The second nice benefit is that API will be easy to go via component system as there is almost no data flow.
I am not sure this can be understood by anyone beside people who talked to Josef in person about these issues already :-) I'll try to restate the idea more clearly, because I think it's pretty important. Josef, please correct my re-statement is wrong.
First, the work "module" is overloaded. It can mean 3 things:
* YaST module (a set of files roughly corresponding to a package and a Git repo)
* YCP module (YCP file that begins with `module "foo"` declaration)
* Ruby module (Ruby syntactic construct)
YCP modules were translated into Ruby. After the translation they are quite heavy-weight, require declaring of published methods/variables and they are global/singleton in nature. They are not natural citizens in RUby world. This is the price for full compatibility with YCP and YaST component system.
The proposal is to use YCP-compatible modules only for public API of given YaST module. Anything internal to the module should be implemented in native Ruby way (using Ruby modules and classes) and placed in the "lib" directory.
-----
I agree with the idea above and personally, I would even like to see some standardization in what goes into the "lib" directory. For example, where the models and views (in the MVC sense) are placed and how they are named.
Thanks for making it more clear. I agree that some standardization would be nice.
3) No includes. Includes is relict from ycp and it should be moved to lib as common ruby class or modules. ( perl and python also doesn't have it )
Yes. No includes in new code.
5) testing framework. We definitively need new one, old one is really horrible to use and fragile. Ruby provide a lot of nice test frameworks, the well known are Test:Unit[2] ( classical test unit framework with asserts ) and RSpec that is designed to fit nice for TDD [3]. I personally use for a long time Test:Unit and try RSpec few months ago and I really like RSpec, especially how tests looks like and how nice is its output.
I would also favor RSpec. Specs written using it are very readable and can be structured nicely.
6) Documentation. For code documentation we translate comments to YARD[4]. But there is also documentation that sits around in docbook format. I found quite hard to write new parts of documentation and keep it up-to-date. I found tool that can convert docbook to textual based markdown format[5]. And I also thing that documentation should be together with code and also examples should live with code. YARD support it in quite nice way (support inlined markdown). See e.g. documentation of ActiveRecord::Base which lives together code and how it can look like [6].
I think it makes sense to use just one format for the technical documentation and YARD is a natural choice here because it's used for documentation comments already.
8) build program. YaST currently use autotools. It has few drawbacks - it is written in different language then rest of plugins ( M4 versus ruby now ), not so popular today ( so less people understand it, especially in ruby community ) and not so easy to share functionality ( currently we use Makefile.am.common and other tricks ). Common ruby build tool is Rake[8], question is if we want use it.
At least for pure Ruby YaST modules, it makes a lot of sense, but there are lot of questions. The most important ones are:
* Do we want to use unified tooling for all YaST modules, or is this not strictly necessary?
Well, even now we use two autotools + cmake. But I found it annoying as yast have few specifics and we need to have helpers for such specifics in both of build tools. So It is not strictly necessary, but it will be really helpful.
* If we want unified tooling, do we want autotools to wrap Rake, or Rake wrap autotools in cases where they are needed (at least C++ code)? Or can Rake do all the work?
I think that Rake can do both and we should unify it - https://github.com/joeyates/rake-builder and http://stackoverflow.com/questions/4272727/rakefile-rules-in-c-project
Maybe some prototyping would be the best way to explore this area.
Yes, we can try it. Of course first part is if we want change old code or use rake for new one or unify it, as it include a lot of file. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org