From: Christoph Rippel <crippel@...>
Date: 2001-01-16T07:40:03+09:00
Subject: [ruby-talk:9347] Re: Redefining singleton methods & C - function pointers


"Dave Thomas" <Dave@PragmaticProgrammer.com> wrote in message
news:m2n1ctvib5.fsf@zip.local.thomases.com...
> "Christoph Rippel" <crippel@primenet.com> writes:
>
> > > That would make object instantiation somewhat difficult....
> > Sorry I am probably (even) slow(er then usual) today. Could
> > you be more specific?  I don't see what problem you would
> > get with object instantiation  if #append_features would
> > adapt the behavior of #new
> > A = Class.new
> > B = Class.new A
> > def A.s
> >     p id
> > end
> > A.s # 83990138
> >
> > B.s # 83990118
>
> Simply that to be consistent, .new is a singleton method, so the

I guess your point is that #append_features is a (private) instance
method (maybe it is private class method by the way?) but #new is a
Class method?

> behavior of .new itself might be tricky if you allowed the inheritance
> of singletons methods.

But the singleton methods of the Class object A are inherited
by the Class object  B.

> Do you have a particular problem in mind?

I was just responding to the comment  that you could simply override
#append_features if are not in content with the current behavior. I  feel
that any  method which does not make explicit use of  ``self'' should be
a module method  - for example  -

module Swap
def Swap.swap(l,r)
    l,r = r,l
end
#and not
def   swap2(l,r)
    l,r = r,l
end
end

- but  this is only a matter of esthetics.  Note  that

p Kernel.singleton_methods.join "  "

produces  a very long list - but I believe that these are only
 ``ghost_singleton_methods'' (please, someone correct  me if I am
wrong  - one way or the other  -  ``ghost_methods'' are weird! )
caused by the auto mixin of the Kernel module into Object, since

p  Kernel.private_instance_methods.join "  "

produces the same list.

Christoph