> But the same would hold for variables. That would mean you could never
> name a variable "time" when there is a class Time. 

So what's the problem? Call it "aTime", "myTime", "startTime", "runTime" or
a gigazillion other names.

> Even if there wasn't a class Time at the point you wrote that code,
> but it is filed in later.

No problem either. Even today you can have temp name and instVar name
clashes. There's no "deep reason" for raising an error (and in fact we don't do it
if you - for example - add an iVar which collides with a temp) only that
*usually* this is a bad idea since it can get confusing (and that's why we raise
an error if you modify a method with any of these clashes). So the rule is
simply temp precedes iVars precedes globals, which is already true for globals
(e.g., pool vars can "override" names in Smalltalk). This problem has been
present since the dawn of computing.

> We have a nice pseudo-name-space for temps now, identified by
> the lower-case first letter. How would you handle that?

Like I said, I wouldn't. Why would I have to?! ;-)

Cheers,
  - Andreas

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!