Hi Alex, thanks for you input, we'll have a look :).
On 01/19/2011 03:39 PM, Axel Rauschmayer wrote: > I love all the stuff that Qooxdoo is able to do with its classes and > compilation, but it does feel a little bit like it has been created > by Java programmers. Well, maybe not exaclty "by", but rather "for" Java programmers, meaning, programmers coming from a classical OO background. And those guys are regularly enthusiastic about qooxdoo for this reason. > For the future, I see a few possibilities to > make it more "JavaScript-ish". 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. Indeed, but I don't think we will drop support for the older ECMA spec anytime soon. NB: I take you are using "qxoo" as a synonym for qooxdoo; but there is actually a distinct package named "qxoo" that comprises just the OO and event layer, and is independent from e.g. browser APIs (e.g. see http://news.qooxdoo.org/download-qxoo-now). > I also wonder if some of the getXXX() methods of the Qooxdoo > API could not be turned into (possibly read-only) properties, then. > 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). > > - 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. This is indeed an issue we'll have to look into. > 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])? > > - 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(?) There is some debate around singletons, but I think they were introduced for conceptual reasons, not because they were considered unavoidable. The same applies to e.g. private class members. > > - 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. Again, qooxdoo's OO model tries to be closer to classical, class-based inheritance, to cater for people coming from that background. > > - CommonJS modules: everyone seems to use them (especially node.js). > Any plans for Qooxdoo? Nothing concrete. Maybe the package concept could be interesting, but other than that I'm not sure, as CommonJS basically defines APIs that apply to non-browser environments. You should be able to use qxoo (the package, see above) there. Adding wrapper classes for CommonJS APIs to the qooxdoo library itself might be a future option if everybody is craving to use qooxdoo in such environments :-). Thanks for your input, T. ------------------------------------------------------------------------------ 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
