Bikeshed: No more Symbol < String?

Hi ruby-core!

It seems matz decided to remove String from Symbol's
ancestors 5 days  
ago:

http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/
string.c.diff? 
r1=1.290;r2=1.291;sortby=date;f=h

irb(main):001:0> :symbol.is_a? String
=> false

I wonder why?
There surely is an interesting and enlightening reason for
the change 

[murphy]

Hi,

In message "Re: Bikeshed: No more Symbol <
String?"
    on Tue, 7 Nov 2006 15:34:15 +0900, Kornelius Kalnbach
<murphyrubychan.de> writes:

|It seems matz decided to remove String from Symbol's
ancestors 5 days  
|ago:

Even though it is highly against DuckTyping, people tend to
use case
on classes, and Symbol < String often cause serious
problems.  I found
several of these even in the standard distribution
libraries.  That
encouraged me to remove String from Symbol's superclass.

							matz.

Sorry for noise. I misread. Go bike.

2006/11/7, Yukihiro Matsumoto <matzruby-lang.org>:
> Hi,
>
> In message "Re: Bikeshed: No more Symbol <
String?"
>     on Tue, 7 Nov 2006 15:34:15 +0900, Kornelius
Kalnbach <murphyrubychan.de> writes:
>
> |It seems matz decided to remove String from Symbol's
ancestors 5 days
> |ago:
>
> Even though it is highly against DuckTyping, people
tend to use case
> on classes, and Symbol < String often cause serious
problems.  I found
> several of these even in the standard distribution
libraries.  That
> encouraged me to remove String from Symbol's
superclass.
>
>                                                        
matz.
>
>


-- 
http://nohmad.sub-port.net

See [ruby-core: 09188]
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/rub
y/ruby-core/9188

2006/11/7, Kornelius Kalnbach <murphyrubychan.de>:
> Hi ruby-core!
>
> It seems matz decided to remove String from Symbol's
ancestors 5 days
> ago:
>
> http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/
string.c.diff?
> r1=1.290;r2=1.291;sortby=date;f=h
>
> irb(main):001:0> :symbol.is_a? String
> => false
>
> I wonder why?
> There surely is an interesting and enlightening reason
for the change 
>
> [murphy]
>
>


-- 
http://nohmad.sub-port.net

Hi --

On Tue, 7 Nov 2006, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: Bikeshed: No more Symbol <
String?"

Is "bikeshed" shorthand for
"unimportant"?   I would
disagree
strongly in this case -- not on a global scale, perhaps, but
in the
context of Ruby programming.

>    on Tue, 7 Nov 2006 15:34:15 +0900, Kornelius
Kalnbach <murphyrubychan.de> writes:
>
> |It seems matz decided to remove String from Symbol's
ancestors 5 days
> |ago:
>
> Even though it is highly against DuckTyping, people
tend to use case
> on classes, and Symbol < String often cause serious
problems.  I found
> several of these even in the standard distribution
libraries.  That
> encouraged me to remove String from Symbol's
superclass.

It sounds like it's related to what Charlie Nutter was
talking about:
the problem that Symbol reduces the "contract" of
String.  I know Ruby
isn't Eiffel   and also
that inheritance in Ruby is, as you once
said, mostly a matter of shared implementation and not
hierarchy.
Still -- I think the change is probably best, not only to
encourage
duck typing but also based on the relation between the two
classes.


David

-- 
                   David A. Black | dblackwobblini.net
Author of "Ruby for Rails"   [1] | Ruby/Rails
training & consultancy [3]
DABlog (DAB's Weblog)        [2] | Co-director, Ruby
Central, Inc.   [4]
[1] http://www.manning.com/b
lack | [3] http://www.rubypower
andlight.com
[2] http://dablog.rubypal.com    | [4] http://www.rubycentral.org

On Nov 7, 2006, at 2:28 AM, Yukihiro Matsumoto wrote:

> Even though it is highly against DuckTyping, people
tend to use case
> on classes, and Symbol < String often cause serious
problems.  I found
> several of these even in the standard distribution
libraries.  That
> encouraged me to remove String from Symbol's
superclass.

Matz, just curious but what was your opinion on the idea of
removing  
Symbol altogether?

I'm pretty sure it was Charles Nutter that made the
suggestion to  
just have :whatever create a frozen String, which is
basically what  
we had with the subclassing.

James Edward Gray II

Yukihiro Matsumoto <matzruby-lang.org> writes:

> Hi,
>
> In message "Re: Bikeshed: No more Symbol <
String?"
>     on Tue, 7 Nov 2006 15:34:15 +0900, Kornelius
Kalnbach <murphyrubychan.de> writes:
>
> |It seems matz decided to remove String from Symbol's
ancestors 5 days  
> |ago:
>
> Even though it is highly against DuckTyping, people
tend to use case
> on classes, and Symbol < String often cause serious
problems.  I found
> several of these even in the standard distribution
libraries.  That
> encouraged me to remove String from Symbol's
superclass.

Thank you.

> 							matz.
-- 
Christian Neukirchen  <chneukirchengmail.com>  http://chneukirchen.org

Hi,

In message "Re: Bikeshed: No more Symbol <
String?"
    on Tue, 7 Nov 2006 23:44:45 +0900, James Edward Gray II
<jamesgrayproductions.net> writes:

|Matz, just curious but what was your opinion on the idea of
removing  
|Symbol altogether?

That may work, but it introduces unnecessary compatibility
issues.  If
I were designing Ruby from scratch now, that might be an
option.

							matz.

David wrote:
> Is "bikeshed" shorthand for
"unimportant"? 
No, it should mean: "Low-Tech Discussion on Ruby,
please accelerate". It
was the first bikeshed example in matz' keynote for RubyConf
2006.
But my mail client seems to think that this is spam (wanna
buy a
b1ke5hed?), so my prefix idea (like [TINY] for Rails
patches) may be  
bad.
I removed it.

Back to topic. matz wrote:
> Even though it is highly against DuckTyping, people
tend to use case
> on classes, and Symbol < String often cause serious
problems.  I found
> several of these even in the standard distribution
libraries.
Yes, I also used "case String" in one of my
libraries. The Ruby 1.8  
and 1.9
compatible fix was very simple: "instance_of?". I
don't have to change
that now. It still seems to be a very reliable solution.

And Duck Typing won't help: Both String and Symbol
respond_to :to_str,
even now. I don't ask to remove Symbol#to_str, it seems
justified,  
but it
also means that String and Symbol quack the same melody.

After thinking about it, I really like the idea of
"automagically"  
created
Symbols by freezing Strings. We have Fixnum<>Bignum
behind the scenes  
(which
is only for performance and memory reasons AFAIK), and the  
Symbol<>String
problem is alike.

When I use Symbols, I care about five things, ordered by
importance:

- easy writing (:bla)
- they save their textual value somehow (for to_s and
inspect)
- they are distinguishable from Strings in some easy and
obvious way
- they save memory (singletons)
- performance (comparison and hashing are fast)

As a programmer, I don't care about:

- how they are represented internally
- the value of object_id (never used it!)
- whether they are mutable or frozen
- how Sring and Symbol are related in the class hierarchy

That's just my opinion. The Symbol <=> String issue
seems to be a  
matter of
how people are using them in 1.8. So, your idea of looking
at stdlibs is
very good, I think.

The current solution works for me. I'm sure we will find the
best way.
[murphy]

On Wed, Nov 08, 2006 at 03:01:41AM +0900, Kornelius Kalnbach
wrote:
> After thinking about it, I really like the idea of
"automagically"
> created Symbols by freezing Strings. We have
Fixnum<>Bignum behind the
> scenes  (which is only for performance and memory
reasons AFAIK), and
> the  Symbol<>String problem is alike.

But Strings as Hash keys are automatically frozen.  This
behavior might
create more Symbols than we want (can you garbage-collect
Symbols once
they are in the symbol table?).

Paul