On Sat, May 24, 2008 at 8:44 PM, David A. Black <dblack / rubypal.com> 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