From: Benjohn Barnes <benjohn@...>
Date: 2007-09-07T02:52:19+09:00
Subject: Re: before, after and around Ruby 1.9


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.

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.

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

Cheers,
	Benjohn