On 9/6/07, Trans <transfire / gmail.com> wrote:
>
>
> 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.

Maybe I read you wrong, there should be a way for metaprogrammers to
know where a method was defined, but that should not be the *only* way
to access to super or redefined methods.
Actually
   super_at(object/module/class)
might be a useful tool, but I would like to have
    super
and
    old (or next or whateverMatzLikes ;)
to just step up one level for "non meta use"
>
> > 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.
Hmm yes sure, but when Matz answered your question about after/before/around
it seemed to me that it would be a special case built in instead a more general.
I might be completely wrong of course ;)
>
> > 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,
true but it would still be an interface decided upon early
>and 2) but
> much more importantly, any such implementation is going to be severely
> hampered in execution efficiency compared to a native capability.
Losing you here, do you mean that special bytecode would be emitted
for these three constructs that would be more efficent than for method
redefinition?
Interesting topic but I am too ignorant of it :(
Cheers
Robert
-- 
I'm an atheist and that's it. I believe there's nothing we can know
except that we should be kind to each other and do what we can for
other people.
-- Katharine Hepburn