From: dblack@... Date: 2003-05-22T00:21:22+09:00 Subject: Re: super, aliases, defadvice, AOP, and so on Hi -- On Thu, 22 May 2003, Hal E. Fulton wrote: > ----- Original Message ----- > From: > > > I have some instinct that tells me that a method cannot, as a general > > matter, "know" that it is replacing an existing method (because it may > > or may not be, depending on dynamically evaluated conditions), but I > > can't quite think my way through it. Perhaps I'll try to babelfish > > thing with Matz's weblog :-) > > Well, I'm in hesitant disagreement. > > The interpreter certainly can "know" that a method > is being redefined; and in keeping with Ruby's > reflective nature, I'd like to see that knowledge > available to the program. At least, I think I would! I guess what I mean is that in writing a method, the person writing it may or may not know, and therefore not know whether to use 'prior'. Example scenario still percolating somewhere in brain :-) > And yes, we'd have to deal with situations where > the feature was used meaninglessly (both static > and dynamic); just as it's possible to use "super" > in a context that makes it meaningless. (In many > cases, this will be caught at so-called "compile > time"; but my gut tells me we could contrive a > scenario where it couldn't be determined until > runtime). Actually I think those are usually caught at runtime. It's essentially a method call, and the method either is or isn't there: irb(main):001:0> class A; def x; super; end; end => nil irb(main):002:0> a = A.new => # irb(main):003:0> a.x NameError: super: no superclass method `x' David -- David Alan Black home: dblack@superlink.net work: blackdav@shu.edu Web: http://pirate.shu.edu/~blackdav