Hey Alex, > - Getters, setters: with ECMAScript 5 supporting them, qxoo should migrate to > them. Using obj.foo instead of obj.getFoo() would be great. 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). I would love to do that but as long as we have a single browser that does not support the __defineGetter__ and __defineSetter__ stuff you talk about, its just not possible. Whole qooxdoo is based on events which rely on the fact that we can execute code when a property is written.
> - 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])? This is a topic we are aware of but haven't made up our mind how we want solve that. Maybe thats something like that, maybe its just referencing the super class with an absolute path. Don't know yet. > - 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(?) Singletons are a well known pattern in software engineering. I'm not a big fan of them either but I would not say that we don't need them. Sure you can have singletons using other ways in JavaScript but still, no reason to drop the support. > - 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. If the only reason is to be more like JavaScript, its really not worth to change such a big thing. Currently the system works as designed and there has to be really good reasons to chance something so elementary in the framework. If every app developed with qooxdoo has to change only a single line, its really not easily changed. > - CommonJS modules: everyone seems to use them (especially node.js). Any > plans for Qooxdoo? Do you really want to trade a dynamic dependency analysis for self maintained modules? I don't think that this would help qooxdoo much. Sure its just a hype thing but I guess qooxdoo would not benefit from moving to modules. Best, Martin ------------------------------------------------------------------------------ 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
