From: Rick DeNatale <rick.denatale@...>
Date: 2007-09-07T09:25:07+09:00
Subject: Re: before, after and around Ruby 1.9

On 9/6/07, Benjohn Barnes <benjohn@fysh.org> wrote:
>
> On 6 Sep 2007, at 06:17, Daniel DeLorme wrote:
>
> > Joel VanderWerf wrote:
> >> What if you want to reopen _without_ the "around" semantics? Could
> >> we have these two variations:
> >> class Foo < Foo       # <-- This is a type error in 1.8
> >>   def foo; super; end # AROUND
> >> end
> >> class Foo
> >>   def foo; super; end # REDEFINE
> >> end
> >
> > +1
> >
> > This is brilliant. It's simple, and it perfectly expresses the idea
> > of reopening the class to add functionality on top of the existing
> > methods. Instead of subclassing a parent class, Foo subclasses
> > itself (sort of like Foo=Class.new(Foo)). Just Brilliant.
>
> :-) I think I'm probably missing something, but I'm not sure that I'm
> keen on this approach though I find the simplicity alluring.
>
> The issue I have is what happens when the class is re-opened more
> than once: when lots of methods get wrapped around? As far as I can
> see, the order of the openings in the code is important, and I don't
> like the feel of that at all. I feel like I ought to be able to
> reorder things such as the order of class definition without that
> having a semantic effect. In fact, I think I find it confusing
> already that if I define the same method more than once for the same
> class, then the last definition will be the one that's used.

Yes, I totally agree, this is a real problem. I fear that things will
all get wrapped up around the axle because it depends on the temporal
ordering of execution.  How do you control this when different parts
of the overall program are dynamically requiring extensions and
redefinitions?  Imagine how this would or wouldn't work in a Rails app
using multiple plugins.
>
> Am I missing something? Does anyone else feel similarly? Is the
> consensus that this wouldn't be an issue in practice?
>
> I suppose I'd prefer something that would somewhat break away from
> what happens now...
>
> I'd have all of the implementations of a method (within the class) be
> called. I'd then have another mechanism for enforcing ordering: a
> syntax that lets an implementation insist that it requires another to
> be run before it (or after it). Once you've insisted that another
> implementation runs before you, then you're able to utilise the
> return state of that method you asked to run before you.

On the surface, I'm not sure that any of the proposed solutions are
any better than what we have now with alias_method and explicit
invocation of the replaced method implementation.

The proposals might make it seem more transparent, but in my
experience, transparency isn't always a good thing when it hides
issues that need to be dealt with.   I've got some experience with
that, since I take the blame for producing a transparent distributed
implementation of Smalltalk which caused all kinds of headaches
because of such hidden issues.


> Then again, what I'm asking for could easily be done with a library,
> so perhaps it's not so important :-)

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/