Re: [RCR] removal of magical definition of name for some class definition idioms

On Sat, May 24, 2008 at 8:44 PM, David A. Black <[e-mail]> wrote:

> I'm not sure what the significance of _ is there. (I mean, I know it's
> a variable name, but is there a special significance to using _ here?)
I just wanted to see what the parser does, well I saw it.
>
> I think it all comes back to the way objects and references work. The
> class object has one name, in the sense that X.name is a method with a
> value. The class doesn't know how many references to it (constants
> and/or variables) exist. In this respect, you can think of name as
> just a kind of cousin of object_id: it's object metadata, not
> identifier metadata.
But that is exactly what it is not, it is identifier metadata that is
pushed into the object, for the convenience of the user of course.
I am trying very hard to think why we can do without it right now, but
I will probably not succeed.
>
>> class x
>> end
>>
>> x.class --> Class
>>
>> I fail to see a reason that
>> x = Class::new is allowed while
>> class x is not
>>
>> Motivation:
>>
>> This would be one of the occasions to make Ruby simpler, not only
>> would we get rid of a magically created attribute acessible by the
>> method Class#name, but the parser would need less work to do.
>
> I don't have an airtight argument for why it makes sense for constants
> to be the preferred or privileged identifiers for classes, but I do
> think it makes sense -- or, at least, that it contributes to a nicely
> balanced language design (where there's a more or less baked-in best
> practice but you don't have to use it).
>
> I see that 1.9 lets you do things like:
>
>>> a = Class.new
>
> => #<Class:0x3a361c>
>>>
>>> a.class_eval { module B; end }
>
> => nil
>>>
>>> a::B
>
> => #<Class:0x3a361c>::B
>>>
>>> a.constants
>
> => [:B]
>
> which does seem to be blurring the distinction between constants and
> non-constants. The problem I have with this is that if it's true that
> constants and non-constants should be blurred, then I don't understand
> what the rationale for the original design was. But I'm probably
> drifting back to the whole :: thing, which I think is quite vexed.
I do not really follow you, but I am still 100% for your :: RCR if we
can get the method with "::" ;)
> Do you really mean remove_method, rather than method_missing? I'm not
> sure I follow.
That comes from pasting around error messages that do not really occur
:(, yup I mean method missing.

Considering what #name is used for this is probably a very stupid post
of OP, who happens to be oooops.
Of course it will be rejected - for practical reasons - and still it
feels so right as an idea. Maybe I need perl 6 ;) or Smalltalk.

Cheers
Robert

-- 
http://ruby-smalltalk.blogspot.com/

---
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein