On Sun, Feb 1, 2009 at 12:03 PM, David A. Black <dblack / rubypal.com> wrote:
>
> They're related conceptually but they also fit into the object model
> nicely: every method is defined in a class or module; every object has
> a lookup path of classes and modules. I know Matz has said that the
> main thrust of per-object behavior is per-object behavior, and that
> the way it's implemented (singleton class, which, like other classes,
> can include modules) is secondary, but there's a tremendous advantage
> to having it blend into the overall landscape

I agree. After all, subclasses lookup class methods in a parent
class's singleton class and clones inherit from an instance's, e.g.

class A
  def self.foo
    "foo"
  end
end
class B < A
end
a = A.new
def a.foo
  "bar"
end
b = a.clone
puts B.foo
puts b.foo

# >> foo
# >> bar

That is hardly secondary behaviour. We can access an instance's class
by name (via object.class) - why not the singleton (or extension)
class?

> I think. I've seen
> literally hundreds of "Ah ha!" moments where people suddenly grasp the
> whole per-object thing because once you get the idea of every object
> having a singleton class, you don't have to learn anything else new
> (with regard to #extend, etc.).

Well, not hundreds in my case, but it's definitely one of those
epiphany moments (along with 'classes are objects too'). I think
naming the elements involved similarly (extend, extension_class,
extension_methods, etc.) would help clarify the relationship between
these concepts.

(As an aside - why is there no method #extended_modules analogous to
#included_modules?)

Regards,
Sean