Hi Axel, thanks for your input and questions.
> I love all the stuff that Qooxdoo is able to do with its classes and > compilation, Great you like it. > but it does feel a little bit like it has been created by Java > programmers No worries, none of the core developers really is a Java person. I guess it's fair to say that we are all advocates of dynamic/scripting languages, i.e. JavaScript pirates by heart. ;-) This doesn't mean we get religious about it, instead try to incorporate concepts and tooling that have proven useful for app development on a larger scale. > For the future, I see a few possibilities to make it more > "JavaScript-ish". Well, whatever that could mean. ES5 might even bring some more options. But at least qooxdoo is 100% JS, thus doesn't need any form of pre-processing, even that its form of OO code organization doesn't look like plain (i.e. primitive) native JS. > This is long-term stuff, but I’m interested in your opinion. > > - Getters, setters: with ECMAScript 5 supporting them, qxoo should > migrate to them. Using obj.foo instead of obj.getFoo() would be > great. Without ES5 being implemented and established throughout the major browsers, this is quite a long way to go anyway. It is also a matter of taste. At the end, we'd have to make sure there is a consistent programming model, and I can't see we'd switch entirely from one form of getters/setters to the other or equally support/feature both of them. > I also wonder if some of the getXXX() methods of the Qooxdoo API could > not be turned into (possibly read-only) properties, then. As you said, only within the possibilities of the ES5 implementations, if at all. A consistent, universal programming model seems to be key here as well, and as such does exist already (and can keep exist). > Cocoa API listings look very clean, because they often use properties > (I don’t program Cocoa, but it looks like all of their binding stuff > is based on them). Many people find Cocoa or rather Objective-C not very appealing. ;-) In any case, we'd strive to keep being a 100% JS framework (or eventually ES5 if you will). If you're hooked on Objective-C, I'd recommend to look into Cappuccino, http://cappuccino.org , which uses a Objective-J. > - Invoking super methods: Currently, you need "arguments" to go to > super. In the upcoming strict mode, arguments.callee will be > forbidden, which makes the current qxoo solution impossible. How about > the Prototype.js solution of introducing an additional parameter > $super (only) if you want to call super (which I have stolen in [1])? Yeah, we know from the standardization process. Devs of other JS frameworks also weren't happy about removing that without offering an equivalent. Anyway, eventually there might be a (tooling-assisted) way of handling that in a future qooxdoo. > - Singletons are a construct from class-based languages that are not > necessary in JavaScript. Instead, you can directly create objects. I’m > guessing qxoo has introduced them to support infrastructure such as > events(?) Sure, there are , even ad-hoc ways of creating (such) objects in native JS, e.g. by the literal form. The qooxdoo singletons are merely tiny, convenient wrappers to align consistently with the rest of the OO layer (and tooling like API generation). Singletons are a pretty fundamental design pattern to support. In real life, you often do better not to use them, though. > - Doing prototypal inheritance: I don’t think it would change much of > Qooxdoo, if it went completely prototypal (see [1]), but it would be > truer to JavaScript’s foundations. I doubt it wouldn't change much in qooxdoo. I also doubt it would be worth the effort to replace the current, mature OO layer/concepts, despite acknowledging the prototypal nature of JS. > - CommonJS modules: everyone seems to use them (especially node.js). > Any plans for Qooxdoo? Sure, there's quite a hype about it. IMHO it's often driven by frameworks that don't yet have a convincing way for modularization, or are targeting specific environments. We'll keep an eye on that. > Thanks for reading! Thanks for sharing! TTYL, Andreas -- Andreas Ecker Project Lead http://qooxdoo.org ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
