Hi --

On Fri, 23 May 2008, Robert Dober wrote:

> Dear list
>
> in a very recent discussion I have realized that to many the meaning
> of Class#name does not make sense or is confusing.
>
> Problem:
>
> X = Class::new
> and even
> X =_ = Class::new

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?)

> delivers "X" as result of X.name
> of course after Y = X we have
> Y.name = "X"
> but we can perfectly reopen X with the following syntax
> class Y
> ...
> end
>
> As I believe that the dynamic semantics of assigning classes to
> constants and variables are far too important to be dropped the
> concept of a name of a class does not really make sense any more. I am
> aware that thinking consequently into this direction should allow us
> to write code like the following too. I release these thoughts for
> comments too :)

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.

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

> Proposal:
>
> The following behavior should be implemented
>
> 535/35 > cat classes.rb && ruby1.9 classes.rb
> # vim: sw=2 ts=2 ft=ruby expandtab tw=0 nu syn=on:
> # file: classes.rb
> class K; end
> p K.name
> classes.rb:5:in `remove_method': method `name' not defined in Class (NameError)
>        from classes.rb:5:in `<class:Class>'
>        from classes.rb:4:in `<main>'

Do you really mean remove_method, rather than method_missing? I'm not
sure I follow.


David

-- 
Rails training from David A. Black and Ruby Power and Light:
   INTRO TO RAILS         June 9-12            Berlin
   ADVANCING WITH RAILS   June 16-19           Berlin
   INTRO TO RAILS         June 24-27           London (Skills Matter)
See http://www.rubypal.com for details and updates!