On Sep 6, 11:54 am, "Robert Dober" <robert.do... / gmail.com> wrote:
> On 9/6/07, Trans <transf... / gmail.com> wrote:
>
>
>
> > On Sep 5, 6:46 pm, Yukihiro Matsumoto <m... / ruby-lang.org> wrote:
> > > Hi,
>
> > > In message "Re: before, after and around Ruby 1.9"
> > >     on Thu, 6 Sep 2007 10:32:03 +0900, Joel VanderWerf <vj... / path.berkeley.edu> writes:
>
> > > |What if you want to reopen _without_ the "around" semantics?
>
> > > I thought we need to remove the previous one first.
>
> > > |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
> > > |
> > > |At least that is a conservative extension.
>
> > > Or maybe providing two supers, one for the current behavior, the other
> > > for the new.  I don't whatever name is suitable for new super yet,
> > > however.
>
> > How would you be sure (and why would you want to?) know when a
> > "previous" exists or not? It rarely make sense to avoid advice.
> > However, when absolutely needed one can fallback to directed calling
> > with things like:
>
> >   super_at(Object)
>
> Inheritance dependecies, oooouch, danger, hot do not touch!

Well, that was kind of my point. As often as this is useful, so is
skipping over around advice.

> Mixin dependecies even worse imagine you want to refer to a mixed in
> method, maybe it was mixed in by an anonymous module, or the method
> was defined at instance level.
>
> After all it feels wrong to have around, before and after built into
> the language, this seems to be a job for the metaprogrammers not for
> Matz.

Why exactly? Ruby has many meta-programming features built-in. That's
part of it's charm and power.

> I'd prefer having an easy way to do this with metaprogramming and then
> put the implementations into the library.

There are two problems with that. 1) any implementation one can create
as an add-on is going to have a less intuitive interface, and 2) but
much more importantly, any such implementation is going to be severely
hampered in execution efficiency compared to a native capability.

T.