[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-core
Subject:    [ruby-core:29298] Re: Proposal: Module#thunk_method
From:       Joshua Ballanco <jballanc () gmail ! com>
Date:       2010-04-07 11:23:45
Message-ID: 05D93878-B723-4615-99BF-DCA64F32E7A4 () gmail ! com
[Download RAW message or body]


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


[prev in list] [next in list] [prev in thread] [next in thread]