Charles I do not have the energy to type all the things I would like to say. So if one day we cross at ESUG I can take a blackboard and explain it. Now in a nutshell The problem is that nested classes implies a really different organization and infrastructure. If we late bound classes then we should copy code (binding are shared between litearl and namespace).... I do not want to enter into the details. Then you end up with the question of "ah ok the superclass is not known at compile time" -> mixin infrastructure: how do I avoid to copy all the code (copy down of accessors and only using accessing....). Then about namespaces. I do not like VW namespaces - I do not like class level import. Now the point is not about namespaces per se. the problem is twofold: - do we want real modularity or just something for nameclash. if you want nameclash, I do not see why prefix are not simpler For real modularity it means that you define your code in isolation and bind the name after in a bind statement and that your scope protect you (for example what happen if the super class is now bound to a class that by accident has the same instance variables than the class you just defined). So you see it changes a lot. - Now the infrastructure (compiled, browser..... should not use Smalltalk globals but environment everywhere so that we can explore namespaces and modules design. So all the people wanting namespaces should be clear for what for themselves first? what is the engineering cost? do they are ready to put this cost on the table? or what other improvement is less important? help just to get tools been able to work on a different environment. So if you payed attention we started since 2002 or even before removing all the Smalltalk at: and turning them in self environment, now recently we got Smalltalk globals and even more recently we got SystemNavigation working on environment instead of hardcoding Smalltalk globals... Having envoironment -based tools (without having namespace in the languages since this is a different issue) will support: system bootstrap atomic loading compiler bootstrap better modular system So let me conclude: - we have a vision - we are not sure what is the best solution (namespace vs. true module) - we are working on the infrastructure so that at least we can prototype some solutions So I hope that may anwser is ok because I will not say more. 1.2 is waiting for us to get born. Stef
Hi, perhaps a bit off topic, but I was wondering from those that brought Traits to ST, what are their thoughts of the use of nested classes such as used in Ruby and other languages.
Good idea? If so should Smalltalk integrate these? Why? Why not ?
thanks in advance
-Charles www.nycsmalltalk.org -- -- View this message in context: http://forum.world.st/Nested-classes-tp3125667p3125667.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.