Hi Stefan,
You are right that in Java you can create classes in a namespace and interleave your classes with the existing, third party library but in Java the only advantage this gives you is access to classes which are local to the package. Qooxdoo doesn't have the concept of package-private classes (AFAIK) so this doesn't apply. The only remaining benefit is that you can have less namespaces? This could be pretty confusing and counter-intuitive for anyone looking at your code in the future, and could mean your code could conflict with future versions of Qooxdoo if they produce a widget with the same name. In 1B, do you mean that if you provide your own implementation of class x.y.Z you can replace the implementation of x.y.Z in another third party library? AIUI this depends on the loading order of classes which is not easily predictable - yes, if you have a class it can replace something in a library but I don't know if that is guaranteed behaviour. The convention for package names in Java is a reversed domain name that you or your company owns - this is a simple mechanism that ensured there would be no conflicts; OK, qx.* and java.* are not in that convention but they are central and well known names. Back in the "good old days" before namespaces, you had to choose a prefix for your functions and hope you didn't get linker errors (ugh - there were only nasty workarounds for that problem). The idea is that everyone "owns" their own domain (i.e. namespace) and _that_ increases the reusability of the framework. John From: Stefan Andersson [mailto:[email protected]] Sent: 09 August 2010 17:50 To: [email protected] Subject: [qooxdoo-devel] Again: generator and namespace with adding modules I appreciate your answers, but to get a flexible framework there must be a flexible way of handling this. 1. I could not find this documented (which means I didn't find it and that means it was not clear enough or whatever!): a. that it is not possible to add new classes in existing namespaces, also qx namespace, without new Manifest.json files (which I have shown it is the only case it works). when you do NOT want to extend classes f.i. adding a missing widget in the namespace and you don't think that grouping should be other place b. that overriding is not possible could be useful, but not really what I wanted cause it might disrupt the library 2. I would do 1a in Java too!!!! 1b is also an option for people who think parts of the framework is not good enough or they want to change functionality but keep the other structure due to compatibility from version to version. Look at the recent thread about performance decrease from one version to another.....!!!!! In that case he has developed new so called light-weight widgets, but for compatibility he might want to use the same namespace = no changing, and then hook in the new ones instead of the old ones!!!! Do you understand me now? This would increase the flexibility and (RE)USABILITY of the framework. Stefan
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
