From: Joshua Ballanco <jballanc@...>
Date: 2010-04-07T20:23:45+09:00
Subject: [ruby-core:29298] Re: Proposal: Module#thunk_method


On Apr 6, 2010, at 9:11 PM, Charles Oliver Nutter wrote:

> define_method can take an argument in place of the block, but it
> expects it to be a Proc or Method and raises an error if it is not. If
> this form were reused for memo_method, it would be impossible to
> memoize a Proc or Method itself, since define_method would try to use
> that Proc or Method value as the *body* of the method. So at least the
> simple define_method(:blah, value) form is out for backward-compat
> reasons.

Well, again I would challenge you as to how often one wants to memoize a Proc or Method, and how often one would want to do that by defining a method...but I feel like this argument could progress until we just re-implement LISP...

> I don't know how to do that, given that define_method always needs
> either a Proc, block, or Method, and in each case has more dispatch
> overhead than either a memoized method or even a normal method. None
> of the implementers have succeeded in making define_method be as fast
> as a regular Ruby method, much less approaching the performance of
> attr_access or a native core method that just returns a value. If you
> have a way to fix this, I'd love to hear it :)

I don't have a fix (yet). And I agree completely that, currently, this would not be an easy optimization to implement by any stretch of the imagination. It just seems to me that the real issue we should be solving is "make this sort of optimization easier to do" rather "more methods to work around difficulty implementing optimizations". Perhaps this is more of a topic for a Ruby 2.0 discussion. I just worry that we're teetering on the brink of overcomplicating the language with extra methods and lookup rules.

- Josh