1. procedural vs. object-oriented ruby
[...]
but, after perusing ops.rb, builtins.rb, and a few .rb files in yast-installation/, it seems to me that we could have a much more natural-looking ruby code if, instead of having Ops.add all over the place we went for Yast::String#+, Yast::Array#+, etc. it seems there's not so many places where we "return nil", and we could "return Yast::String.new", "return Yast::Array.new" etc in such places.
This was considered and rejected. Going this way would mean that either new code would also need to use Yast::String, Yast::Array, etc., or would have two parallel systems in one codebase. I found both highly undesirable -- much more than Ops.*, etc. Going with native classes is more future-oriented and simpler.
2. optimization/simplification opportunities in y2r
this might not be a representative example, i haven't seen it all. i looked through yast-installation/src/clients/desktop_finish.rb for opportunities to remove some Builtin.foreach calls. it took me about 30 minutes (first encounter with builtins.rb, ops.rb etc) to realize that there's *no reason* for @desktop_order to be pulled through Builtins.foreach: it's always an array. the next thing on my mind was: if *i* can see this, why not the transpiler?
We were operating under the constrain that we need to ship in openSUSE 13.1 (to be included into SLE12). No sophisticated static analysis leading to the optimizations you describe was possible in that time frame with our resources.
the questions here are: is it too late now? if yes, is ther a tool that would let us transform the ruby code? (pls no sed(1) jokes ;) i can see how adding such optimization phases to y2r could require slight changes (hints) to the ycp code, and i don't expect it to do inter-module analysis (though that would enable most gains).
I think we should forget YCP now and do any optimizations purely on Ruby code. That said, I don't know about any tools that could help us with that significantly.
i'm afraid that we're going to get stuck with most of the generated code for the next 10 years. there's ~9k lines with Ops.add alone across the generated code, total number of uses of these @deprecated methods will be quite a bit higher, and if we're going to do the analysis (as opposed to a computer), it'll take a very long time, and we're bound to introduce more bugs than the computer would.
I agree and I would be against mass changes without help of some tools. In reality, I think most code will stay in the current form because it is not touched too much. For active code, I suppose it will be converted into more Ruby-like style gradually as people will work on it. -- David Majda SUSE Studio developer http://susestudio.com/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org