From: Ruby Newbie <rubynewbie@...>
Date: 2006-06-14T23:45:50+09:00
Subject: Re: Cut-based AOP

------=_Part_91145_14089719.1150296346072
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

transfire - from your response, it would seem that AOP for ruby is alive and
kicking - is work moving forward to include Cut within Ruby proper?  If so,
would you expect it in a 1.8.x release or later?


On 6/14/06, transfire@gmail.com <transfire@gmail.com> wrote:
>
>
> Francis Cianfrocca wrote:
> > >>>Well, saying that is sort-of like programming Turbo Pascal in the
> 80's
> > and saying "I have yet to need OOP". AOP is not just a little side
> > utility, it's a whole new angle on coding. <<<
> >
> > I'm looking for ways to put *harder* shells around pieces of well-tested
> and
> > well-designed functionality, not for ways to slice them open even more.
> The
> > article you cite makes a big deal out of "loose-coupling" (the buzzword
> of
> > the decade) as a goal for AOP. I'd rather accomplish that with
> asynchronous
> > messaging.
> >
> > Austin is right, we don't need AOP.
>
> One can argue the merits (or lack there-of) of AOP all you want. But I
> think you and Audtin are being overbarring to tell others they don't
> need AOP. That's not your choice. And I don't see Ruby as something so
> draconian. There is nothing adverse to the ability to,
>
> require 'cuts'
>
> if one so chooses.
>
> Implementation unfortuately is a bit tricky, and a pure Ruby
> implementation is impossible, but it's not that far off, and I'm sure
> if Matz and Peter Vanbroekhoven got together they could iron out a way
> for it to be reasonably implemented as an optional .so. Any way you
> slice it, Ruby can only benefit from such analystic work.
>
> T.
>
>
>

------=_Part_91145_14089719.1150296346072--