Asp Forum - Why was the "Symbol is a String"-idea dropped?

enduro

5/12/2007 7:16:00 AM

Hello,

I was exited when I heard that
Symbol was made a subclass of String
in Ruby 1.9, September last year.

But then I heard that the experiment
was stopped after only two months.

And recently I have started to think about this
topic again and I've tried to collect the reasons
why the idea was not pursued any longer.

I have not been very lucky searching the net
for that, that's why I am asking you:

Could someone give me a summary of the reasons
why the approach to make Symbol a subclass of String
is not considered for future Ruby versions anymore?
Or point me towards some information explaining that?

Thank you very much

Sven

11 Answers

Brian Candler

5/12/2007 1:28:00 PM

On Sat, May 12, 2007 at 04:20:10PM +0900, enduro wrote:
> I was exited when I heard that
> Symbol was made a subclass of String
> in Ruby 1.9, September last year.
>
> But then I heard that the experiment
> was stopped after only two months.
>
> And recently I have started to think about this
> topic again and I've tried to collect the reasons
> why the idea was not pursued any longer.
>
> I have not been very lucky searching the net
> for that, that's why I am asking you:
>
> Could someone give me a summary of the reasons
> why the approach to make Symbol a subclass of String
> is not considered for future Ruby versions anymore?
> Or point me towards some information explaining that?

The two objects have very different behaviours, so why should one be a
subclass of the other?

* Symbols are immutable, Strings are mutable
* Symbols are singletons, Strings are not

I think this is an example of the traditional OO dilemma: "is Circle a
subclass of Oval, or is Oval a subclass of Circle?" One argument says: a
Circle is a subclass of Oval because you can use an Oval to draw a Circle -
you just need to constrain its parameters. Another argument says: an Oval is
a subclass of Circle because it extends the behaviour of Circle.

Ruby says: we don't care. Make a Circle class, and make an Oval class. Make
them both respond to whatever methods make sense (e.g. all shapes may be
expected to have a 'draw' method). If you want to share implementation code
between them, then use a mixin.

Regards,

Brian.

Trans

5/12/2007 3:20:00 PM

On May 12, 9:27 am, Brian Candler <B.Cand...@pobox.com> wrote:
> On Sat, May 12, 2007 at 04:20:10PM +0900, enduro wrote:
> > I was exited when I heard that
> > Symbol was made a subclass of String
> > in Ruby 1.9, September last year.
>
> > But then I heard that the experiment
> > was stopped after only two months.
>
> > And recently I have started to think about this
> > topic again and I've tried to collect the reasons
> > why the idea was not pursued any longer.
>
> > I have not been very lucky searching the net
> > for that, that's why I am asking you:
>
> > Could someone give me a summary of the reasons
> > why the approach to make Symbol a subclass of String
> > is not considered for future Ruby versions anymore?
> > Or point me towards some information explaining that?
>
> The two objects have very different behaviours, so why should one be a
> subclass of the other?
>
> * Symbols are immutable, Strings are mutable
> * Symbols are singletons, Strings are not
>
> I think this is an example of the traditional OO dilemma: "is Circle a
> subclass of Oval, or is Oval a subclass of Circle?" One argument says: a
> Circle is a subclass of Oval because you can use an Oval to draw a Circle -
> you just need to constrain its parameters. Another argument says: an Oval is
> a subclass of Circle because it extends the behaviour of Circle.
>
> Ruby says: we don't care. Make a Circle class, and make an Oval class. Make
> them both respond to whatever methods make sense (e.g. all shapes may be
> expected to have a 'draw' method). If you want to share implementation code
> between them, then use a mixin.

There are a number of advantages to sub-classing that I can think of:

1) No need to do x.to_s.some_string_method.to_sym

2) Hash keys could efficiently equate symbol and string keys (it's
the distinction that should be optional)

3) It's conceptually simpler: a Symbol is an immutable String.

I'm sure there are a few more. On the downside, Symbols might not be
as efficient in general, and there could be some back-compatibility
issues.

Would be interesting to know what effectively killed the official
attempt at this.

T.

Rick DeNatale

5/12/2007 3:31:00 PM

On 5/12/07, Brian Candler <B.Candler@pobox.com> wrote:
> On Sat, May 12, 2007 at 04:20:10PM +0900, enduro wrote:
> > I was exited when I heard that
> > Symbol was made a subclass of String
> > in Ruby 1.9, September last year.
> >
> > But then I heard that the experiment
> > was stopped after only two months.

>
> The two objects have very different behaviours, so why should one be a
> subclass of the other?
>
> * Symbols are immutable, Strings are mutable
> * Symbols are singletons, Strings are not
>
> I think this is an example of the traditional OO dilemma: "is Circle a
> subclass of Oval, or is Oval a subclass of Circle?" One argument says: a
> Circle is a subclass of Oval because you can use an Oval to draw a Circle -
> you just need to constrain its parameters. Another argument says: an Oval is
> a subclass of Circle because it extends the behaviour of Circle.

More a dilemma with languages which force implementation inheritance
to track a notion of type inheritance.

Such languages assume that somehow type hierarchies are natural and
objective. In reality they aren't.

Years ago I was discussing this with Brad Cox, and he came up with
another example. In a strongly typed OO language you might have a
hierarchy like this:

class Object
class Vehicle < Object
class Automobile < Vehicle
class Car < Automobile
class Truck < Automobile
class Ambulance < Truck

So an ambulance is a specialized truck.

But then in a new context you might want to model a ski resort and now
an ambulance can be either a toboggan, or a helicopter.

These are the kind of things which tie strongly typed frameworks in
knots of implementation tangled with type.

> Ruby says: we don't care. Make a Circle class, and make an Oval class. Make
> them both respond to whatever methods make sense (e.g. all shapes may be
> expected to have a 'draw' method). If you want to share implementation code
> between them, then use a mixin.

Or in other words, languages like Ruby provide fairly rich mechanisms
for sharing implementation, and don't tangle this up with policy
decisions about how objects should be classified, which in the real
world can become messy, or at least context/requirements dependent.

If anyone wants to ponder the difficulties of making an objective
type/classification hierarchy in more depth, I'd recommend reading the
essay "What , if Anything, is a Zebra" by Stephen Jay Gould, or for a
more in-depth and challenging read, "Women, Fire, and Dangerous
Things" by George Lakoff
--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

Rick DeNatale

5/12/2007 4:41:00 PM

On 5/12/07, Trans <transfire@gmail.com> wrote:

>
> There are a number of advantages to sub-classing that I can think of:
>
> 1) No need to do x.to_s.some_string_method.to_sym

Well, let's see. Why do we do symbol.to_s ?

1). When we want a string representation of the symbol so that we
can say mutate it. Subclassing won't help here.
2) If we want to compare a string with a symbol. Making Symbol a
subclass of string alone won't do this, and if we change Symbol#== so
that :a == "a" is true we destroy one of big advantages of Symbols
which is the speed of determining that two symbols are equal based on
their identity, this is why, for example, symbols rather than strings
are used as method selectors.

And why do we do string.to_sym, primarily because we want the speed
advantages of symbols in comparisons.

> 2) Hash keys could efficiently equate symbol and string keys (it's
> the distinction that should be optional)

No I think that we'd actually get the worst here, it falls out of #2
above. Symbol hash keys are more efficient than String hash keys
because of identity.

> 3) It's conceptually simpler: a Symbol is an immutable String.
No it isn't. A symbol is an object with an immutable string as a
name, and which is the sole instance with that name.

Now an interesting idea might be to add more string methods to Symbol
so that for example one could do

:a + :b #=> :ab

So that there was more of a Symbol algebra which was still closed so
that the results were still Symbols.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

Robert Dober

5/13/2007 7:50:00 AM

On 5/12/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
> On 5/12/07, Trans <transfire@gmail.com> wrote:
<snip>
> Now an interesting idea might be to add more string methods to Symbol
> so that for example one could do

:a <=> :b and including Compareable automatically
I think that would be the most useful.
<snip>> Rick DeNatale
>
> My blog on Ruby
> http://talklikeaduck.denh...
>
>
For the rest I rather agree with Rick's POV.
If one subeclasses a class X with a class Y, one conceptionally says
"an instance of Y" is "an instance of X".
Could you say a Symbol is a String? No you cannot unless a Symbol
responds to all messages of a String. In other words, subclasses
extend the behavior of baseclasses they never restrict it.
Well that holds for my old OO stuff I have learnt, maybe I have to
change paradigm, but right now I am not convinced.

Cheers
Robert

--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw

Xavier Noria

5/13/2007 8:21:00 AM

Just wanted to point out that the original question is why Ruby core
changed their mind, not what people think in general about relating
String and Symbol. Perhaps the question could be sent to ruby-core as
well.

-- fxn

Robert Dober

5/13/2007 8:33:00 AM

On 5/13/07, Xavier Noria <fxn@hashref.com> wrote:
> Just wanted to point out that the original question is why Ruby core
> changed their mind, not what people think in general about relating
> String and Symbol. Perhaps the question could be sent to ruby-core as
> well.
That is indeed a good idea
>
> -- fxn
>
>
Neverheless we are spot on the thread, are we not? And even if we were
drifiting to a related topic that sometimes gives the best
discussions.

But maybe our arguments are not convincing?
What would you want to discuss then?

I do not feel one should be that rigid about OnTopic OffTopic.
Well just my 0.02 whatever money you worship.

Cheers
Robert
>

--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw

Xavier Noria

5/13/2007 9:04:00 AM

On May 13, 2007, at 10:32 AM, Robert Dober wrote:

> On 5/13/07, Xavier Noria <fxn@hashref.com> wrote:
>> Just wanted to point out that the original question is why Ruby core
>> changed their mind, not what people think in general about relating
>> String and Symbol. Perhaps the question could be sent to ruby-core as
>> well.
> That is indeed a good idea
>>
>> -- fxn
>>
>>
> Neverheless we are spot on the thread, are we not? And even if we were
> drifiting to a related topic that sometimes gives the best
> discussions.
>
> But maybe our arguments are not convincing?

I think that if a couple of simple arguments make clear both classes
should be unrelated the core team wouldn't even bothered to start
relating them. So I guess it's likely that there's more into it and I
would like to know about it.

> What would you want to discuss then?
>
> I do not feel one should be that rigid about OnTopic OffTopic.
> Well just my 0.02 whatever money you worship.

The discussion itself is OK for me. I just wanted to point out that
the original question has not been answered, otherwise the thread
could engage in talking about what people think in general and forget
it.

-- fxn

Marcin Raczkowski

5/13/2007 10:13:00 AM

On Saturday 12 May 2007 07:20, enduro wrote:
> Hello,
>
> I was exited when I heard that
> Symbol was made a subclass of String
> in Ruby 1.9, September last year.
>
> But then I heard that the experiment
> was stopped after only two months.
>
> And recently I have started to think about this
> topic again and I've tried to collect the reasons
> why the idea was not pursued any longer.
>
> I have not been very lucky searching the net
> for that, that's why I am asking you:
>
> Could someone give me a summary of the reasons
> why the approach to make Symbol a subclass of String
> is not considered for future Ruby versions anymore?
> Or point me towards some information explaining that?
>
> Thank you very much
>
> Sven

basic reason - as stated in ruby hacking guide is that Symbol internally is
just Int !

that makes hash based on symbols much much faster, as a consequence of above
Symbol is "read-only" and you can modify String as much as you want.

so to sum up - Symbols are smaller, faster, but "read-only", good for indexing
hashes - passing methods names etc.
Strings - heavy, slow, but with greater flexability,

if you want more in deep explenations read ruby internals/hacking guide

--
Marcin Raczkowski
---
Friends teach what you should know
Enemies Teach what you have to know

rett

5/13/2007 6:37:00 PM

Rick,

Aren't we confusing symbol with operator in this discussion. If I am
dealing
with a program as a string or group of strings, as any compiler
initially must,
not having symbols as a part of strings makes my initial task almost
impossible.

Everett L.(Rett) Williams II

Rick DeNatale wrote:
> On 5/12/07, Trans <transfire@gmail.com> wrote:
>
>>
>> There are a number of advantages to sub-classing that I can think of:
>>
>> 1) No need to do x.to_s.some_string_method.to_sym
>
> Well, let's see. Why do we do symbol.to_s ?
>
> 1). When we want a string representation of the symbol so that we
> can say mutate it. Subclassing won't help here.
> 2) If we want to compare a string with a symbol. Making Symbol a
> subclass of string alone won't do this, and if we change Symbol#== so
> that :a == "a" is true we destroy one of big advantages of Symbols
> which is the speed of determining that two symbols are equal based on
> their identity, this is why, for example, symbols rather than strings
> are used as method selectors.
>
> And why do we do string.to_sym, primarily because we want the speed
> advantages of symbols in comparisons.
>
>> 2) Hash keys could efficiently equate symbol and string keys (it's
>> the distinction that should be optional)
>
> No I think that we'd actually get the worst here, it falls out of #2
> above. Symbol hash keys are more efficient than String hash keys
> because of identity.
>
>
>> 3) It's conceptually simpler: a Symbol is an immutable String.
> No it isn't. A symbol is an object with an immutable string as a
> name, and which is the sole instance with that name.
>
> Now an interesting idea might be to add more string methods to Symbol
> so that for example one could do
>
> :a + :b #=> :ab
>
> So that there was more of a Symbol algebra which was still closed so
> that the results were still Symbols.
>

comp.lang.ruby

Why was the "Symbol is a String"-idea dropped?

enduro

Brian Candler

Trans

Rick DeNatale

Rick DeNatale

Robert Dober

Xavier Noria

Robert Dober

Xavier Noria

Marcin Raczkowski

rett

x Login to ForumsZone