On Sun, Jan 30, 2011 at 02:35:26PM +0100, Stanislav Višňovský wrote:
So what seems desirable and feasible? Some ideas:
1) Replace YCP with some common language? With more that 100 modules this looks impossible.
I think this is a good and the only viable option if YaST code should survive in long run.
The knowledge of YCP internals is slowly forgotten and the language is stalled for some time now.
In short, I agree with Stano. YCP has many shortcomings, the elephant in the room being its lack of object orientation. Of course we will have to maintain YCP to keep the existing code in the existing products working. But for new development, *anything* is better than YCP, simply by virtue of being widespread. (Even Perl seems not to be write-only lately: http://www.onyxneon.com/books/modern_perl/ )
2) Allow a common language next to YCP? A good integration seems difficult.
I see this as step towards goal 1).
Yes. It may be difficult but I see no alternative.
3) Improve YCP (at least fix bugs)? Do we want that?
What kind of bugs do you see in YCP? There is only a couple of them I'm aware of and they can be easily workarounded. In this regard, I don't think it's worth trying to fix them.
Let me distinguish YCP as the language and YCP as the interpreter and data model. Even if we phase out the language, the interpreter needs improvements as it is the means through which the widespread-language bindings communicate with old code. In particular I mean the thing I mentioned in the call: Enabling to write real test suites, by allowing to mock other APIs than SCR agents. Otherwise we cannot refactor and risk that simple maintenance will mutate the project to an untouchable state. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu