From: dblack@... Date: 2003-01-18T08:14:23+09:00 Subject: Re: quick: it responds, it evaluates, and is not empty Hi -- On Sat, 18 Jan 2003, ahoward wrote: > that's at least the second time i've forgotten about that method. i've never > really understood why there cannot be > > class Symbol > def initialize str > ... > end > end > > which i would NOT forget about... See -- there was a (rejected) RCR for Symbol.new, with some commentary from Matz. > [I wrote:] > > > For me there are two problems with the exception-wrapping idiom: > > speed, and the absence of an exception which precisely and uniquely > > corresponds to "this object did not respond to that message." > > NameError can represent a case where the method got called but, > > itself, tried to call a non-existent method on an object. > > good point. but wouldn't simply returning NACK from method missing accomplish > this? (see my other post) Yes, I would assume it would be implemented as some kind of hook into, and/or wrapper around, method_missing. The issues this would raise would then have to do with minimizing impact on objects that already have a method_missing... so I think it would have to be included or extended into particular objects (including classes) selectively. (And it's probably not thread-safe, because no ideas I ever have are thread-safe :-) Here's my latest iteration, based on code posted in this thread and my own tinkerings: class Method NACK = Class.new.class_eval { require 'singleton' include Singleton }.instance module Nacker def method_missing(*args) NACK end end end # Class-wide inclusion class A include Method::Nacker end # Object extension s = "abc" s.extend(Method::Nacker) # Demo p A.new.no_such_method == Method::NACK # true p s.no_such_method == Method::NACK # true David -- David Alan Black home: dblack@candle.superlink.net work: blackdav@shu.edu Web: http://pirate.shu.edu/~blackdav