From: David Simmons Date: 2001-11-29T10:14:07+09:00 Subject: [ruby-talk:26851] Re: Selector Namespaces: A Standard Feature for Smalltalk? "Doc O'Leary" wrote in message news:281120011449424672%droleary@subsume.com... > In article , David > Simmons wrote: > > > Namespaces are just > > one small but fundamental key in the overall puzzle of the problem space(s) > > covered by my work. However, the post itself was specifically on an aspect > > of namespaces and thus it did focus entirely on that area and its potential > > value. > > I figured that, which is why I also figured we weren't really > disagreeing as much as it seemed. > > > The idea [I think you are alluding to] of modules and renaming/aliasing of > > classes and messages is a "namespace" system; just with a different name (no > > pun intended). The assumption that a "string of characters" is involved in > > the internals/implementation would not be correct for SmallScript's > > implementation (my work in this area) -- SmallScript/AOS actually flattens > > [and tracks] the textual-namespace view through strong-names using uuid's > > [otherwise, namespaces can be very problematic in versioning and > > refactoring]. > > I'm not making an assumptions on the implementation of SmallScript, or > any other language. What I'm trying to get across is that aliasing is > fundamentally different from the way namespaces are handled for a > developer under most/all current implementations. The problems come > about because namespaces, like the classes and methods themselves, are > choosen by the *vendor* and not the integrator/developer. As such, > they don't really offer me any real power when I'm putting components > together. If I have my own String class but want to integrate somebody > else's String class because it uses a character array interface, I want > to be able to refer to it as CharacterArray, not com.somevendor.String > or whatever the vendor has decided I should be calling it. O' contraire. At least in SmallScript namespaces (aliasing/importing other namespace elements on a per/item basis) you would just write: Class name: String { ... } Which allows me to then reference the other namespaces class everywhere as . These are first-class aliases. Which means that deployed binary code which references them does not need to be recompiled to change the alias to something else. I.e., Compiler cmds: '-target:dll'. Module name: Z version: 1 imports: MyNamespace { Function [ blah ^CharacterArray ] } /* Which, using dynamic MOP facilities, I can then re-assign to be an alias to some other class. Not that a user would do this, but this illustrates the facility (which tools might use). */ . Requires module: Z. Function [ Initialize MyNamespace[#CharacterArray] := SomeOtherClass. ]. Function[ TestIt stdout cr << CharacterArray asNamespacePath. "" Would emit primary name. ] > The same is > true for methods, where I have in my head and in my program the concept > of getting a character at a particular location in the array, and it > would make more sense to use a valueAtLocation method instead of the > characterAtIndex method the vendor liked. This is also solved, safely, for you, with selector namespaces (and can also be done via different means with selector aliasing, or AOP services). "" Which we will scope explicitly for good measure Method behavior: CharacterArray scope: MyNamespace [ valueAtLocation: anIndex "declare optional type for good measure" ^self characterAtIndex: anIndex ] > In short, whatever the > solution is needs to put the power into the hands of the > developer/integrator to be really useful, and namespaces simply don't > do that. I think I've illustrated that your sweeping (namespace) generalism is not true. > > > I'm with you on the design comments up to the last sentence on "silver > > bullets". For me, the business outcome is still what ultimately matters and > > that is where I perceive we differ [I prioritize business success as being > > an essential requirement, so when hard choices must be made, it outweighs my > > strong feelings about design]. I.a., no matter how much "good design there > > is", given a complex system integration 3rd/other party issues can always > > come into play to break a design surreptitiously and heaven knows where the > > finger pointing ends -- and the clients don't care they just want a working > > solution. > > Again, we mostly agree here. The problems come from the, shall we say, > "backwash" from compromised implementation. A wonderful design might, > for example, involve adding a method or methods to an existing class, Which is a basic feature of almost every dynamic language [and I'm of course focused on SmallScript which is an extended dialect of Smalltalk]. > but the implementation might be in a language that doesn't have proper > category support, so a subclassing or some other solution might be > used. /* SmallScript examples of the very features you mentioned above */ "" A method with multiple categories using general "" annotation tags that are reflectively queryable Method [<'category.sub-category...';'another...'> selector ] "" Another category declaration format Class name: Foo categories: abc.def; bar... { } "" Or use concrete interfaces... Category name: AnInterfaceCategory { "" Methods or other category decls "" for this first class type } Class name: Blah implements: AnInterfaceCategory. > That would be fine, but I too often see that then the > implementation language begins to impact the design until the people > designing the system are crippled by the limited abilities of some C++ > grunts trying to crank out code. Ooooo, I *hate* it when that happens! > :-) Well, that's why dynamic languages that are "real-OO" with full reflection and rich MOP services for extending them are much better than the popular "object-oriented" languages. -- Dave S. [www.smallscript.org]