Hi --

> Problems 1 and 2b are, IMO, ultimately a symptom of all method names on an
> object falling into the same namespace. The only way consistent way to
> separate them is by including a namespace as part of the method name. Using
> the object's class name would be one solution:
>
>    Object#object_class
>    Object#object_send
>    Object#object_private_methods
>    Object#object_singleton_method_added
>    ...
>
> There is already a precedent here: Object#id was renamed to Object#object_id

The precedent thing is always tricky, though.  One could also say:
this has already happened once, so we've filled the quota :-)  Also, I
think #object_id was 100% about the difficulties with name conflicts,
which isn't an issue with #singleton_method_added.

> However, a full solution to problem 2b would involve *all* methods on Object
> being in a separate namespace. This quickly becomes stupid:
>
>    Object#object_is_a?
>    Object#object_nil?
>    Object#object_eql?
>    Object#object_to_s
>    ...
>
> Should it also apply to other built-in modules like Kernel (included in
> every object) or Enumerable (included in many objects)?
>
>    Kernel#kernel_puts
>    Enumerable#enumerable_collect
>    ... etc?
>
> I think not. But if we choose some other basis for namespaces (e.g. "normal"
> versus "metaprogramming") then again this crucially depends on recognising
> which methods fall into which category, arguing this for each method.

And that's why I'd rather not get "meta" about it.  It seems to me
that determining categorization for each method cannot be *better*
than determining what the method does and naming it based on that. In
particular, getting into an open-ended debate about what is and isn't
metaprogramming in Ruby is, I think, unpromising and wasteful.

> Problem 7 is true of all keywords in the language, i.e. you can't have a
> local variable or bare method name called 'if' or 'end'. It's a symptom of
> keywords, local variables and receiverless method names falling into the
> same namespace. I assume you don't want to tag these things Perl-style.
>
> Since the set of reserved words in Ruby is very small, I don't think this is
> a problem normally when choosing your own method names. But I agree that
> it's unfortunate that Ruby has decided to use a name for a *built-in* method
> which is also a reserved word.
>
> From that point of view, I'd be happy to see #class changed to
> #object_class, in the same way that #id was changed to #object_id

I'm personally in favor of #birth_class and #singleton_class, but I
don't think that has much traction.

> (Incidentally, which of these are metaprogramming? What about "extend",
> "taint", "freeze", "respond_to?")

Good question. My view is that it's all programming.[1] I think of the
term "metaprogramming", in connection with Ruby at least, as a
description of what the programming does, rather than what a given
method does.


David

[1] See, e.g., http://dablog.rubypal.com/2007/1/7/meta-shmeta-learning-ruby-horizontally

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
   (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)