From: "James A. Robertson" Date: 2001-11-27T09:07:30+09:00 Subject: [ruby-talk:26574] Re: Selector Namespaces: A Standard Feature for Smalltalk? Doc O'Leary wrote: > In article , David > Simmons wrote: > > >>Problem: Two unrelated Smalltalk developers are creating modules for >>handling monetary units [grossly simplified]. >> > > This is not the problem, of course; it happens all the time. And based > on the massive cross posting that > > >>A third party integrator comes along and has the requirement of writing a >>program that requires both US and Canadian currency operations. They are >>given the requirement that they must use the party-one's and party-two's >>packages (rather than writing their own). They may even be in the >>uncomfortable but likely position that they do not have source to the >>packages [as would commonly be the case for static languages and platforms >>based on binary component approaches like .NET]. >> > > Finally we see the problem: a screwed up development process. What you > like to possibly hide behind words like "pragmatic" and "real-world" I > call a complete FUBAR. Why not solve the real problem instead of > hacking away at the programming language until it begins making as > little sense as the managers concocting requirement? Sigh. Ok. Here's something that happened in VW back during the 2.5.2 and 3.x cycle. We started including an enhanced inspector. That enhanced inspector replaced system code here and there, but worked fine - until you wanted to load a commonly used package - the PDP debugger from one of our third parties. Both packages were useful simultaneously, but both changed many of the same methods in similar ways to suit their own purposes. At this point, you could have one or the other (but not both) in the same image. And guess what? Versioning does for me here. We had two different outside developers working independently on packages that developers wanted to use . What people ended up doing was hacking the code (because they had source) to get both to work. Had they been binary loadable components with no source, SOL. Versioning doesn't address this issue at all. > > >>Now we have a serious problem. Both parties have made implementations that >>appear to conflict. First, without namespaces the class name will >>collide. Even with namespaces, the #asMoney methods on , will >>conflict. Since the #asMoney methods (minimally) yield unrelated return >>types. I.e., one party returns a unit of Candian and the other >>party returns a unit of US . >> > > Given that these are the issues, I can see many other solutions that > are more reasonable than simply throwing namespaces at it. How about a > form of class aliasing/casting? Just because the developer liked the > name Dollars for the class shouldn't prevent me from referring to it as > DollarsUS (and DollarsCanada). You might think of that as nothing more > than a reworked namespace solution, but it is in reality much > different. In my experience, namespaces tend to be vendor-specific > instead of API-specific, so things like com.sun.String and > com.apple.String aren't just drop in replacements for each other. By > using a better mechanism, you would enable different classes that *are* > drop in replacement to be reference by just changing the alias instead > of modifying the code everywhere to refer to a different namespace. > > The same could be supported for methods, allowing the client to > essentially rename them as appropriate for a particular use, possibly > even then implementing their own asMoney method to call the country > specific code based on the string being parsed (I do this sort of thing > myself when parsing addresses in my InstantLinks software). > > >>Now our 3rd party, who needed to implement a single application that used >>both libraries can do so without conflicts. >> > > I notice you're big on writing the code that defines these things, but > you never seem to show the usage. The biggest problem with namespaces > is that using them makes the code more difficult to understand and > maintain. I have a feeling that people who are in favor of namespaces > don't really use them a lot. > > >>The classes are distinguished through namespaces (remembering that >>modules are classes and classes are namespaces). Both classes >> and comfortably exist. >> > > I wouldn't call two different and unrelated Dollars implementations a > comfortable situation. You have just forced the developer to > understand the particular of both objects when dealing with currency, > not to mention any additional objects that get patched in should other > currency be supported. With no unifying superclass, you've created a > program that will be a bear to work with. This is simply poor OO. > > >>If our 3rd party wants to write code that references both libraries they >>will need to specify the particular namespaces they are referring to. Let's >>assume they decide to write code to convert both Canadian and US dollars. So >>they would like to have methods called #asCanadianDollars and #asUSDollars, >>but they want to be insulated from implementation changes provided by party >>one and/or party two's version updates. >> > > Why the hell, as a developer, do I have to know and tell the string > what form of currency it represents? You're discarding yet another OO > principle, that of polymorphism, in defining those methods. There > should properly be, still, a simple asMoney method that would give a > localized object for the representated currency. And this is to say > nothing of having to later on use a different module that offers > currency support (possibly even US and/or Canadian), but with a > different API than either of the two you've been using. Now you have > to pour through the code and patch up everything to use the new > namespaces and method names. Namespaces solve nothing real here. >