On Fri, 14 May 2004 20:18:52 +0900, Robert Klemme <bob.news / gmx.net> wrote:

> That's not how namespaces work (at least in C++).  First, class String in
> MyNames is a totally new String class that has nothing to do with any
> other class with the same name unless you inherit that class.  Second,
> "xxx" is a literal that is bound to the standard type String (char* in
> C/C++), similarly as 1.234 is bound to represent a float.  You don't
> change that by introducing namespaces.  Third, places in code that create
> strings one way or the other will always create standard strings.  If the
> declaration of a new class with the same name as another class in a
> different namespace had the side effect that *all* places in code now use
> the new class, type safety would be completely down the drain - apart 
> from
> all other sorts of problems (how should a compiler handle this in C++?).
>
> What you'd rather want is a mechanism that replaces the binding of 
> certain
> literals to types ("xxx" => String, 1.234 => float etc.).  But then, in
> Ruby it's far easier to simply extend String.  Still I think in most 
> cases
> it is not a good idea to use a sub class of String as an application
> class, since that brings all sorts of problems with it.
>

I don't think so.
Even if you statically type, you have

namespace A

  class String
  end

  x = "xxx"  # syntactic sugar for String.new("xxx")
             # statically looking up constant String resolves to A::String
             # => A::String.new("xxx")

end

In C++ the OO is broken IMHO, because "" is not an object, rather
a char* pointer, which doesnt fit with namespaces.

extending the String class messes up the namespace,
imagine a 100k lines project, where everyone extends the String
class. Either you get long method names or name crashes will be likely.

A problem is passing the A::String outside the namespace,
i think in this case the string object should'nt respond
to A::String methods.

Besides that A::String is not simply a subclass of string.


>> Recently I attended a lecture of the creator(Erik Ernst) of the
>> language gbeta, which solves this problem nicely, but
>>  from a very different approach.
>
> How do they do it there?

A:
   (# String:<
     (# somemethod: ... #);
   #)

B: A
   (# String::< (# othermethod: ... #);
    #)

So here A is a class and B is a subclass of A.

In B there will be created a fresh copy of String
extending String with a new method.

-- 
Matthias Georgi
matti_g / gmx.de