On 1/4/07, ara.t.howard / noaa.gov <ara.t.howard / noaa.gov> wrote:
> On Thu, 4 Jan 2007, Devin Mullins wrote:
>
> >
> >> If given a choice between a method that works and one
> >> that might work, which one would you choose?
> > The simple one. Here, __* are all unlikely to be overridden (and well, can't
> > - Ruby should stop you from overriding them). __ is a flag that this is a
> > special thing that can't be overridden. It's ridiculously ugly, as a sign
> > that it should be used sparingly, both by the language designers and by
> > users. Finally, the names are short, for when you *are* writing metacode.
> >
> > My point was that we need not extract the cool methods into Pervasives in
> > order to achieve metaprogramming simplicity.
> >
> > (On a side note: How do you find the true class of a BlankSlate?)
>
> Pervasives.class obj
>
> ;-)
>
> -a

Interesting. I found this sort of odd though:

Pervasives.class Pervasives

Not really a bad thing since it is rather contained, but still a little odd.

One idea is to provide a module like Pervasives that is mixed in
rather than external. Object could then make use of those directly and
you could then do this:

class Object
  inlude Pervasives # really done in the ruby C code during setup.
  undef_meth :__send__
end

Pervasives.instance_method(:__send__).bind(obj).call(:my_message)

Of course a little help from the module might be nice as well:

# Better name?
Pervasives.deliver obj, :__send__, :my_message

Of course, the second one isn't too far off from the original idea but
this does allow both a standard mixin approach and a functional
approach to be used.

Brian.