In article <tjgM7.46546$RG1.24417339 / news1.rdc1.sfba.home.com>, David
Simmons <david.simmons / smallscript.com> 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?

> Now we have a serious problem. Both parties have made implementations that
> appear to conflict. First, without namespaces the class name <Dollars> will
> collide. Even with namespaces, the #asMoney methods on <String>, will
> conflict. Since the #asMoney methods (minimally) yield unrelated return
> types. I.e., one party returns a unit of Candian <Dollars> and the other
> party returns a unit of US <Dollars>.

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 <Dollars> classes are distinguished through namespaces (remembering that
> modules are classes and classes are namespaces). Both classes
> <USCurrency.Dollars> and <CanadianCurrency.Dollars> 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.