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

Yukihiro Matsumoto

5/13/2007 4:07:00 PM

Hi,

In message "Re: Why was the "Symbol is a String"-idea dropped?"
on Sun, 13 May 2007 17:20:49 +0900, Xavier Noria <fxn@hashref.com> writes:

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

We once changed Symbol as subclass of String to see how it goes, and
met many compatibility problems. People distinguishes Symbols and
String far more than we expected. So we just abandoned the idea.

matz.

44 Answers

Trans

5/14/2007 4:57:00 PM

On May 13, 12:07 pm, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
> Hi,
>
> In message "Re: Why was the "Symbol is a String"-idea dropped?"
> on Sun, 13 May 2007 17:20:49 +0900, Xavier Noria <f...@hashref.com> writes:
>
> |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.
>
> We once changed Symbol as subclass of String to see how it goes, and
> met many compatibility problems. People distinguishes Symbols and
> String far more than we expected. So we just abandoned the idea.

That's unfortunate. IMHO it's generally bad practice to functionally
differentiate between them. But this being the official status now, I
don't see any reason to accept string hash keys for method options
anymore. It's just not worth the extra code and computation to do so.

T.

enduro

5/15/2007 1:07:00 AM

Thank you all for your replies.

And thank you, Xavier, for keeping the focus on my original intention.
Yes, I was not asking about general arguments for designing a class
hierarchy, but for the reasons for this particular decision of the
ruby-core team.

And I was indeed enlightened by matz's answer:

>On May 13, 12:07 pm, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
>
>
>>Hi,
>>
>>In message "Re: Why was the "Symbol is a String"-idea dropped?"
>> on Sun, 13 May 2007 17:20:49 +0900, Xavier Noria <f...@hashref.com> writes:
>>
>>|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.
>>
>>We once changed Symbol as subclass of String to see how it goes, and
>>met many compatibility problems. People distinguishes Symbols and
>>String far more than we expected. So we just abandoned the idea.
>>
>>
This tells me, that it was mainly the weight of the existing ruby usage,
that flipped the balance towards the conservative side.

Or, in other words: if the decision to unify Symbol and String would
have been taken at early stages of Ruby development, then the
general usage would have adapted to this, and ...
we might be happier with the result today.

At least, that is my private opinion on this question:

It is tempting to say: "Symbols are just integers internally,
they are just isolated points in 'Symbol-space',
so it is not suitable to give them string methods."
But I think in practice this is not true:
- Symbols are a standard data type for meta-programming
(and immediately, there will be a need to append a "?" here and then,
or test for some regexp-condition...)
- Symbols are fast as Hash keys,
but the "real-world" keys often are strings, or even can be both,
and then the current situation creates the well-known dilemma
to decide for a Symbol/String interface (and implement it).
Yes, this gives us programmers the freedom to optimize the code...
(... but I think a standard solution would serve better in most cases.)

Yes, I sometimes think of that separation of Symbol from String
as a tiny impurity in the Ruby crystal.

I thought Ruby 2.0 could have been a chance to iron this out.
But it seems that now only small changes are still possible.

So, I'll just have to come to terms with it. :-)
(And I will, of course -- there are enough other fascinating issues... :-) )

Along the lines of Trans:

>That's unfortunate. IMHO it's generally bad practice to functionally
>differentiate between them. But this being the official status now, I
>don't see any reason to accept string hash keys for method options
>anymore. It's just not worth the extra code and computation to do so.
>
>T.
>
>

Before I close, just a small thought regarding the issue that
subclasses are usually extended from their superclass, and not restricted.
I don't know if that had been discussed before: would it perhaps be good to
create a class hierarchy similar to the Float/Integer hierarchy?
String < Stringlike
Symbol < Stringlike
Of course with everything set up such that hash[:a] is the same as
hash["a"] etc.
(Just a thought, probably this already has been rejected.)

Anyway, I'd like to thank the core programmers for all the work
they have put into Ruby to make it shine.
Kind regards,
Sven

Brian Candler

5/15/2007 7:30:00 AM

On Tue, May 15, 2007 at 10:07:24AM +0900, enduro wrote:
> It is tempting to say: "Symbols are just integers internally,
> they are just isolated points in 'Symbol-space',
> so it is not suitable to give them string methods."
> But I think in practice this is not true:
> - Symbols are a standard data type for meta-programming
> (and immediately, there will be a need to append a "?" here and then,
> or test for some regexp-condition...)
> - Symbols are fast as Hash keys,
> but the "real-world" keys often are strings, or even can be both,
> and then the current situation creates the well-known dilemma
> to decide for a Symbol/String interface (and implement it).

The programs for which it makes sense to convert strings (received from some
external source, e.g. a database) to symbols for optimisation purposes, i.e.
where the benefits are measurable, will be pretty few. And you also open
yourself to a symbol exhaustion denial-of-service.

That is, as far as I know, the symbol table is never garbage collected. Once
a symbol, always a symbol.

So using literal symbols as hash keys makes sense:

{ :foo=>1, :bar=>2 }

but using

h = {}
h[a.to_sym] => 1

is risky, and unlikely to yield measurable benefit. If 'a' is already a
String, then there is no benefit from avoiding object creation, since it's
been already done. So you may as well leave it as a String.

> Yes, I sometimes think of that separation of Symbol from String
> as a tiny impurity in the Ruby crystal.

I would disagree with you there, because Symbols are clean and easy to
understand.

There are other "impurities" I can think of - like the seven or so different
flavours of Proc object which have subtle different semantics. This I find
more difficult, because it's really hard to remember the rules for how they
differ. But things like this are here to make the language "do the right
thing" in most practical cases. And, once you've used Ruby for a while, you
find that actually it does.

> I thought Ruby 2.0 could have been a chance to iron this out.
> But it seems that now only small changes are still possible.

I'd vote strongly against anyway. I *like* Symbols as they are. I also don't
feel a dichotomy. Use a symbol where necessary (i.e. for method names) and
for literal hash keys, e.g. named arguments. For anything else a string is
just fine.

I agree it's a bit annoying when you come across a bit of code which
violates the standard practice: e.g. net/telnet uses
{ "Prompt" => /foo/ }
instead of
{ :prompt => /foo/ }

But then even :Prompt would have been annoying, because generally people
don't use the capitalisation either.

Do you think that hash['a'] and hash['A'] should be the same?

Regards,

Brian.

Robert Klemme

5/15/2007 9:31:00 AM

On 15.05.2007 03:07, enduro wrote:
>>> We once changed Symbol as subclass of String to see how it goes, and
>>> met many compatibility problems. People distinguishes Symbols and
>>> String far more than we expected. So we just abandoned the idea.
>>>
> This tells me, that it was mainly the weight of the existing ruby usage,
> that flipped the balance towards the conservative side.

Which is not a bad thing in itself.

> Or, in other words: if the decision to unify Symbol and String would
> have been taken at early stages of Ruby development, then the
> general usage would have adapted to this, and ...
> we might be happier with the result today.

I am in no way unhappy with the way it is today. Strings and symbols
serve different purposes although there is some overlap. I rarely feel
the need to convert between the two.

> - Symbols are fast as Hash keys,
> but the "real-world" keys often are strings, or even can be both,
> and then the current situation creates the well-known dilemma
> to decide for a Symbol/String interface (and implement it).

I am not aware of a situation where you would need to mix them as hash
keys. And to make the distinction is pretty easy most of the time IMHO.

> Yes, this gives us programmers the freedom to optimize the code...
> (... but I think a standard solution would serve better in most cases.)

Frankly, I believe there is an inherent advantage that you can use
symbols vs. strings in code. And I mean not only performance wise but
also readability wise.

Note though, that all these issues have nothing to do with the question
whether String and Symbol should be connected inheritance wise. IMHO
that's mostly an implementation decision in Ruby.

> Yes, I sometimes think of that separation of Symbol from String
> as a tiny impurity in the Ruby crystal.

Personally I believe it creates more expressiveness. If you view this
as impurity, there are a lot of them in Ruby because Ruby's focus has
always been on pragmatism and not purity (although it goes pretty far in
some areas, for example it avoids the POD vs. object distinction that
Java has (I would say this is a pragmatic decision because it makes
things easier if you have a common base class for *all* types)).

> I thought Ruby 2.0 could have been a chance to iron this out.
> But it seems that now only small changes are still possible.

From what I gather Ruby 2.0 will have some major changes, for example
in the area of scoping. Though it's probably done in a way that it will
reduce the impact on existing programs.

> So, I'll just have to come to terms with it. :-)
> (And I will, of course -- there are enough other fascinating issues...
> :-) )

The capability to adjust to reality is a useful one IMHO. :-)

> Before I close, just a small thought regarding the issue that
> subclasses are usually extended from their superclass, and not restricted.
> I don't know if that had been discussed before: would it perhaps be good to
> create a class hierarchy similar to the Float/Integer hierarchy?
> String < Stringlike
> Symbol < Stringlike

Why not? StringLike could even be a module that relies solely on [] and
length to do all the non mutating stuff.

> Of course with everything set up such that hash[:a] is the same as
> hash["a"] etc.
> (Just a thought, probably this already has been rejected.)

I'm not sure whether this is a good idea. Given the fact that I don't
mix symbols and strings as Hash keys I wouldn't benefit - but it would
not hurt me either. :-) YMMV

> Anyway, I'd like to thank the core programmers for all the work
> they have put into Ruby to make it shine.

Definitively! Credits also go to the community that is still among the
most civilized online communities I know so far!

Kind regards

robert

enduro

5/15/2007 9:42:00 AM

Hello Brian,

Brian Candler wrote:

>On Tue, May 15, 2007 at 10:07:24AM +0900, enduro wrote:
>
>
>>- Symbols are fast as Hash keys,
>> but the "real-world" keys often are strings, or even can be both,
>> and then the current situation creates the well-known dilemma
>> to decide for a Symbol/String interface (and implement it).
>>
>>
>The programs for which it makes sense to convert strings (received from some
>external source, e.g. a database) to symbols for optimisation purposes, i.e.
>where the benefits are measurable, will be pretty few.
>
Yes, I agree.
(That's what I tried to address by the two lines after the quote above,
perhaps I should have put a smiley in there :-) )

>And you also open yourself to a symbol exhaustion denial-of-service.
>
>
Yes, of course.
But my point is: Let the system take care of that.
I want a Ruby that just works - crystal-clear, transparently, reliably.
:-)
And it already does in most cases. And there is a lot that can be improved.
And one such improvements could be a garbage collection for symbols. (I
think.)

>That is, as far as I know, the symbol table is never garbage collected. Once
>a symbol, always a symbol.
>
>
I'm not a core programmer, maybe i am asking to much,
but I think it should be possible without slowing anything down.
One very simple idea I can think of, is the following:
Set a limit to the number of symbols and if it is reached
the GC wil be invoked in a special symbol-mode, marking all symbols that are
still in use and completely re-generates the symbol-table from scratch.

>>Yes, I sometimes think of that separation of Symbol from String
>>as a tiny impurity in the Ruby crystal.
>>
>>
>
>I would disagree with you there, because Symbols are clean and easy to
>understand.
>
>
Yes, I really must admit, I also like the cleanness of current Symbols.
But then, my experience is that this clearness is not worth a lot,
because the border towards "dirty" strings must be crossed often.
(That's why I called sticking to the clearness "temping" in my last post.)

>There are other "impurities" I can think of - like the seven or so different
>flavours of Proc object which have subtle different semantics. This I find
>more difficult, because it's really hard to remember the rules for how they
>differ.
>
Fully agree! But that must be a different thread.

>But things like this are here to make the language "do the right
>thing" in most practical cases. And, once you've used Ruby for a while, you
>find that actually it does.
>
>
OK. But that can be said for most programming languages.
We are dealing with Ruby here,
and the appealing thing of Ruby is: the language!
I mean: concise syntax, flexiblity, expressiveness,
allowing to express things *naturally*.
Ruby is not yet good in many other aspects:
speed, threads, documentation.
But the runtime engine can be improved with time,
documentation can grow.
The language is the crystal. It must be good in the beginning,
it becomes more solid with every project written in that language.

So, I'd like to use the time we still have before Ruby 2 is born,
to contribute to a really good language.

>Do you think that hash['a'] and hash['A'] should be the same?
>
>
No, not for the builtin Hash#[].

So long

Sven

Robert Dober

5/15/2007 9:43:00 AM

On 5/14/07, Trans <transfire@gmail.com> wrote:
>
>
> On May 13, 12:07 pm, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
> > Hi,
> >
> > In message "Re: Why was the "Symbol is a String"-idea dropped?"
> > on Sun, 13 May 2007 17:20:49 +0900, Xavier Noria <f...@hashref.com> writes:
> >
> > |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.
> >
> > We once changed Symbol as subclass of String to see how it goes, and
> > met many compatibility problems. People distinguishes Symbols and
> > String far more than we expected. So we just abandoned the idea.
>
> That's unfortunate. IMHO it's generally bad practice to functionally
> differentiate between them. But this being the official status now, I
> don't see any reason to accept string hash keys for method options
> anymore. It's just not worth the extra code and computation to do so.
>
> T.
>
I really like the idea of using symbols as parameter keys exclusively,
I think we would get closer to named parameters instead of emulating
them.
And the interesting stuff is, I always hated String keys in parameter hashes.
Does this go together with the fact that I really like the good old
Symbols are not Strings paradigm? Probably.

But right to now I fail to see what would be the gain from making
symbols mutable.
I still maintain the POV that immutable Symbols must not be a subclass
of String.

Any more thoughts?

Cheers
Robert
>
>

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

Robert Dober

5/15/2007 9:50:00 AM

On 5/15/07, enduro <sven715rt@suska.org> wrote:
> Thank you all for your replies.
>
> And thank you, Xavier, for keeping the focus on my original intention.
> Yes, I was not asking about general arguments for designing a class
> hierarchy, but for the reasons for this particular decision of the
> ruby-core team.
I really have not taken offense. However if you are interested in that
only you might post to ruby-core only.
I am kind of surprised that the considerations of Rick and YHS are
considered as OT.
If you do not like them maybe it would be polite to ignore them. But
talking about the topic on *this* list and ignoring all background
information about what symbols are and have been is kind of weird.
Please remember that Ruby has its inheritance in other languages
owning symbols as I believe to have pointed out.
The fact that the original idea is a big paradigm shift does not
answer your question?

I honestly do not understand that.

Threads just evolve I do not feel that they belong to OP :).
They do not belong to me either of course ;).
Cheers
Robert

>
> And I was indeed enlightened by matz's answer:
>
> >On May 13, 12:07 pm, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
> >
> >
> >>Hi,
> >>
> >>In message "Re: Why was the "Symbol is a String"-idea dropped?"
> >> on Sun, 13 May 2007 17:20:49 +0900, Xavier Noria <f...@hashref.com> writes:
> >>
> >>|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.
> >>
> >>We once changed Symbol as subclass of String to see how it goes, and
> >>met many compatibility problems. People distinguishes Symbols and
> >>String far more than we expected. So we just abandoned the idea.
> >>
> >>
> This tells me, that it was mainly the weight of the existing ruby usage,
> that flipped the balance towards the conservative side.
>
> Or, in other words: if the decision to unify Symbol and String would
> have been taken at early stages of Ruby development, then the
> general usage would have adapted to this, and ...
> we might be happier with the result today.
>
> At least, that is my private opinion on this question:
>
> It is tempting to say: "Symbols are just integers internally,
> they are just isolated points in 'Symbol-space',
> so it is not suitable to give them string methods."
> But I think in practice this is not true:
> - Symbols are a standard data type for meta-programming
> (and immediately, there will be a need to append a "?" here and then,
> or test for some regexp-condition...)
> - Symbols are fast as Hash keys,
> but the "real-world" keys often are strings, or even can be both,
> and then the current situation creates the well-known dilemma
> to decide for a Symbol/String interface (and implement it).
> Yes, this gives us programmers the freedom to optimize the code...
> (... but I think a standard solution would serve better in most cases.)
>
> Yes, I sometimes think of that separation of Symbol from String
> as a tiny impurity in the Ruby crystal.
>
> I thought Ruby 2.0 could have been a chance to iron this out.
> But it seems that now only small changes are still possible.
>
> So, I'll just have to come to terms with it. :-)
> (And I will, of course -- there are enough other fascinating issues... :-) )
>
> Along the lines of Trans:
>
> >That's unfortunate. IMHO it's generally bad practice to functionally
> >differentiate between them. But this being the official status now, I
> >don't see any reason to accept string hash keys for method options
> >anymore. It's just not worth the extra code and computation to do so.
> >
> >T.
> >
> >
>
> Before I close, just a small thought regarding the issue that
> subclasses are usually extended from their superclass, and not restricted.
> I don't know if that had been discussed before: would it perhaps be good to
> create a class hierarchy similar to the Float/Integer hierarchy?
> String < Stringlike
> Symbol < Stringlike
> Of course with everything set up such that hash[:a] is the same as
> hash["a"] etc.
> (Just a thought, probably this already has been rejected.)
>
> Anyway, I'd like to thank the core programmers for all the work
> they have put into Ruby to make it shine.
> Kind regards,
> Sven
>
>

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

enduro

5/15/2007 10:31:00 AM

Robert Klemme schrieb:

> On 15.05.2007 03:07, enduro wrote:

>> Or, in other words: if the decision to unify Symbol and String would
>> have been taken at early stages of Ruby development, then the
>> general usage would have adapted to this, and ...
>> we might be happier with the result today.
>
> I am in no way unhappy with the way it is today.
> Strings and symbols serve different purposes although there is some
> overlap.
> I rarely feel the need to convert between the two.

I see.
And I am quite surprised. Because judging from your online activity
you seem to have some experience.
Perhaps it is also my programming style: I may use symbols where one
normally would use strings.

> I am not aware of a situation where you would need to mix them as hash
> keys.
> And to make the distinction is pretty easy most of the time IMHO.

Not aware? I mean Rails mixes them, right?

> Frankly, I believe there is an inherent advantage that you can use
> symbols vs. strings in code.
> And I mean not only performance wise but also readability wise.

Readability-wise: precisely what advantage?
The only thing that comes to my mind just now, is
that a separated Symbol class easily provides
distinct special values for a parameter that would normally carry a String.

> Note though, that all these issues have nothing to do with the question
> whether String and Symbol should be connected inheritance wise.
> IMHO that's mostly an implementation decision in Ruby.

Yes, I agree.
I am actually interested in the implications for the programmer.
My original question just arised out of the notion
that this implementation decision could have been a move
in a (to my mind) favourable direction.

>> Yes, I sometimes think of that separation of Symbol from String
>> as a tiny impurity in the Ruby crystal.
>
>
> Personally I believe it creates more expressiveness.
> If you view this as impurity, there are a lot of them in Ruby because
> Ruby's focus
> has always been on pragmatism and not purity

1. The core structure must of course be large enough, and a large
structure may look impure.
2. But regarding this particular question: My original notion was that
keeping
Symbol and String too separate is not pragmatic.
(I may change my mind on that, if I read more posts like yours,
though.)

>> So, I'll just have to come to terms with it. :-)
>> (And I will, of course -- there are enough other fascinating
>> issues... :-) )
>
> The capability to adjust to reality is a useful one IMHO. :-)

Well, yes, sometimes I'm glad someone tells me that. :-)

>> create a class hierarchy similar to the Float/Integer hierarchy?
>> String < Stringlike
>> Symbol < Stringlike
>
> Why not? StringLike could even be a module that relies solely on []
> and length to do all the non mutating stuff.

Ah, interesting. Can't follow the implications right now.

> Given the fact that I don't mix symbols and strings as Hash keys I
> wouldn't benefit -
> but it would not hurt me either. :-) YMMV

Yes that was the idea behind it: to benefit some and not to hurt the others.

> Credits also go to the community that is still among the most
> civilized online communities I know so far!

Indeed, I'm experiencing it right now!
Thanks a lot!

Sven

Robert Klemme

5/15/2007 10:55:00 AM

On 15.05.2007 12:31, enduro (Sven Suska) wrote:
> Robert Klemme schrieb:
>
>> On 15.05.2007 03:07, enduro wrote:
>
>>> Or, in other words: if the decision to unify Symbol and String would
>>> have been taken at early stages of Ruby development, then the
>>> general usage would have adapted to this, and ...
>>> we might be happier with the result today.
>>
>> I am in no way unhappy with the way it is today. Strings and symbols
>> serve different purposes although there is some overlap. I rarely feel
>> the need to convert between the two.
>
> I see.
> And I am quite surprised. Because judging from your online activity
> you seem to have some experience.
> Perhaps it is also my programming style: I may use symbols where one
> normally would use strings.

Yeah, maybe. So where are you using symbols where one normally would
use strings?

>> I am not aware of a situation where you would need to mix them as hash
>> keys. And to make the distinction is pretty easy most of the time IMHO.
>
> Not aware? I mean Rails mixes them, right?

I don't use Rails. :-)))

>> Frankly, I believe there is an inherent advantage that you can use
>> symbols vs. strings in code. And I mean not only performance wise but
>> also readability wise.
>
> Readability-wise: precisely what advantage?

If I see a symbol being used as a Hash key I immediately know (or rather
guess) that there is only a limited amount of them and they are known
beforehand, like with options.

# silly example
opts = {
:length => 12,
:width => 30,
}
# other code
resize( opts[:length] )

Whereas when strings are used it's typically stuff that is read from
somewhere, like (another silly example):

ruby -aF: -ne 'BEGIN { $c=Hash.new(0) }; $c[$F[1]]+=1; END { $c.each
{|k,v| print k, "=", v, "\n"}}' /etc/passwd

> The only thing that comes to my mind just now, is
> that a separated Symbol class easily provides
> distinct special values for a parameter that would normally carry a String.

Don't forget the optical distinction between using 'string', "string"
and :symbol.

>> Note though, that all these issues have nothing to do with the question
>> whether String and Symbol should be connected inheritance wise. IMHO
>> that's mostly an implementation decision in Ruby.
>
> Yes, I agree.
> I am actually interested in the implications for the programmer.
> My original question just arised out of the notion
> that this implementation decision could have been a move
> in a (to my mind) favourable direction.

As we all have different habits what may be favorable for one may be
regrettable for the other. :-)

>>> Yes, I sometimes think of that separation of Symbol from String
>>> as a tiny impurity in the Ruby crystal.
>>
>> Personally I believe it creates more expressiveness. If you view this
>> as impurity, there are a lot of them in Ruby because Ruby's focus
>> has always been on pragmatism and not purity
>
> 1. The core structure must of course be large enough, and a large
> structure may look impure.

This somehow reminds me of
http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompletene...

> 2. But regarding this particular question: My original notion was that
> keeping
> Symbol and String too separate is not pragmatic.
> (I may change my mind on that, if I read more posts like yours,
> though.)

Just reread mine a few times - then you don't need the other postings
any more. That's more efficient - you'll save bandwidth and reading is
actually faster if you know the text already. :-))

>>> So, I'll just have to come to terms with it. :-)
>>> (And I will, of course -- there are enough other fascinating
>>> issues... :-) )
>>
>> The capability to adjust to reality is a useful one IMHO. :-)
>
> Well, yes, sometimes I'm glad someone tells me that. :-)

:-)) No sweat - following visions is useful as well. As always it's
the mix...

>>> create a class hierarchy similar to the Float/Integer hierarchy?
>>> String < Stringlike
>>> Symbol < Stringlike
>>
>> Why not? StringLike could even be a module that relies solely on []
>> and length to do all the non mutating stuff.
>
> Ah, interesting. Can't follow the implications right now.

For example regexp matching might be implemented similarly for both
(i.e. just in one place). But then again, since RX functionality is
highly integrated into the language that might not be a good idea - or
the C code needs to become more complex to react differently if it sees
a String or Symbol vs. some custom class that includes this module. Hm...

>> Given the fact that I don't mix symbols and strings as Hash keys I
>> wouldn't benefit -
>> but it would not hurt me either. :-) YMMV
>
> Yes that was the idea behind it: to benefit some and not to hurt the
> others.

The next best thing to a win win situation. :-))

>> Credits also go to the community that is still among the most
>> civilized online communities I know so far!
>
> Indeed, I'm experiencing it right now!
> Thanks a lot!

You're welcome. Thank /you/!

Kind regards

robert

enduro

5/15/2007 11:07:00 AM

Ooops!

sorry if I came across rude in any way.

I don't want to "own" the thread.
But I am interested in my question,
so I was glad that someone repeated it,
at a time when all the answers up to that point had not yet answered it.

Robert Dober schrieb:

> The fact that the original idea is a big paradigm shift does not
> answer your question?

Sorry, no. If someone had told me that this fact was the basis for the
decision of the core team,
that would have answered my question.
(Because the fact alone is not compelling: If a paradigm shift is
possible and good then why not shift?)

And also, I thought that this was the right place for posting the question.
(Actually, until yesterday I didn't know that I could post on ruby-core,
I thought it was just for "cracks", because it's read-only on
ruby-forum.com)

Kind Regards
Sven

And here again, Robert Dober's full text:

> On 5/15/07, enduro <sven715rt@suska.org> wrote:
>
>> Thank you all for your replies.
>>
>> And thank you, Xavier, for keeping the focus on my original intention.
>> Yes, I was not asking about general arguments for designing a class
>> hierarchy, but for the reasons for this particular decision of the
>> ruby-core team.
>
> I really have not taken offense. However if you are interested in that
> only you might post to ruby-core only.
> I am kind of surprised that the considerations of Rick and YHS are
> considered as OT.
> If you do not like them maybe it would be polite to ignore them. But
> talking about the topic on *this* list and ignoring all background
> information about what symbols are and have been is kind of weird.
> Please remember that Ruby has its inheritance in other languages
> owning symbols as I believe to have pointed out.
> The fact that the original idea is a big paradigm shift does not
> answer your question?
>
> I honestly do not understand that.
>
> Threads just evolve I do not feel that they belong to OP :).
> They do not belong to me either of course ;).
> Cheers
> Robert

Another question:
Who is

> YHS

?

Regards, Sven

comp.lang.ruby

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

Yukihiro Matsumoto

Trans

enduro

Brian Candler

Robert Klemme

enduro

Robert Dober

Robert Dober

enduro

Robert Klemme

enduro

x Login to ForumsZone