hello, two topics re y2r (i know i'm horribly late to the party).
1. procedural vs. object-oriented ruby the generated ruby code consists, to a large degree, of function calls emulating semantics of basic ycp operations: Builtins.foreach, Ops.add, etc. these functions are @deprecated, meaning we should go and replace them with native ruby equivalents after checking that the conversion is safe. the point of these emulations is that ycp's nil is a NullObject, you can iterate it like an empty hash or list, you can add it to a number (you'll get nil back), you can concat it with a string or list (same), whereas in ruby you need to if/else around it as stuff like nil.each generates NoMethodError exceptions. 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. 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? 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'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. https://github.com/roman-neuhauser/yast-installation/compare/master...builtins - @desktop_order is initialized with the array literal, so we know the type - it has no getter/setter, so no problems from those - it is reassigned by Builtins operations called on itself; they are guaranteed to return Array if they received one -- roman -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
