From: Robert Klemme <bob.news@...>
Date: 2004-05-14T21:28:52+09:00
Subject: Re: [RCR] subclasses of string as hash keys


"Matthias Georgi" <matti_g@gmx.de> schrieb im Newsbeitrag
news:opr7zs75r77zr67k@mail.gmx.net...
> 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")

Not quite: it's completely up to the language spec what "xxx" stands for.
If if there were namespaces in Ruby it would not mean that the lookup you
describe would happen.  And if asked, I'd strongly vote against it because
this easily messes up a lot of code.

> 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.

That's the exact reason why I recommend to not do it.

> 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.

This will create lots of errors.  Assume someone has any instance from
namespace A and invokes to_s on that instance.  He expects a String but he
gets a A::String which doesn't even support the same interface.  Bang!
This automated changing of string literals to something else is complete
nonsense.  Plus, you'd have to explain how you implement A::String if
"xxx" is already a A::String.  You would have to write a C extension to
handle memory management etc. since you don't have access to the standard
String here. etc. pp.

> 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.

That's possible in all OO languages - even with Ruby.  The crucial point
is how usage of this type is regulated.

It seems to me you're stuck in some dead end street.  Better sleep a night
over this.

    robert