Asp Forum - Re: before, after and around Ruby 1.9

Trans

9/6/2007 4:18:00 PM

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)

or

as(Object).foo

T.

6 Answers

Robert Dober

9/6/2007 6:54:00 PM

On 9/6/07, Trans <transfire@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!
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.
I'd prefer having an easy way to do this with metaprogramming and then
put the implementations into the library.

if there were a method object tree rather than a stack and if each
method object just had references to the defining Module/Singleton
Module, would we not be *very* happy?

module A
def a; 222 end
end
module A
def a; 132 end
end
class B
include A
def a; 110 end
end
class C < B
def a; 60 end
end

class C
include Module::new{ def a ; 52 end }
end

c = C.new
ma = c.method :a
ma = ma.unbind
ma.bind(c).call => 52
ma.old.bind(c).call => 60
ma.super.bind(c).call => 110
and most importantly

D= Class::new {
define_method :a { -3 + ma.bind(self).call - 3 }
}
D.instance_method(:a).old == ma => true

Cheers
Robert
>
> or
>
> as(Object).foo
>
> T.
>
>
>

--
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

Robert Dober

9/6/2007 6:56:00 PM

Ahh the emotion go the better of me ;)
D= Class::new(C) {
define_method :a { -3 + ma.bind(self).call - 3 }
}
D.instance_method(:a).super == ma => true

Sorry for the ugly error

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

Trans

9/6/2007 7:30:00 PM

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.

Robert Dober

9/7/2007 8:30:00 AM

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

Trans

9/7/2007 11:51:00 AM

On Sep 7, 1:30 am, "Robert Dober" <robert.do...@gmail.com> wrote:
> On 9/6/07, Trans <transf...@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"

Yes, that's a common consideration, but there's a subtle reason why
you don't really want that, which is what I'm trying to get across.

When someone writes an around advice, they expect it be wrap the the
method being advised. If the programmer of the original method used
#super rather than #old, it wouldn't work. And that's bad. Because the
point is, I should be able to advise any method I want.

Of course, there may arise special cases where skipping advice in
needed, but that is a rare/dangerous meta-coding need, in which case
#super_at should be more than enough to satisfy the requirement, eg.
super_at(self.class) for instance.

> > 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?

No no. I simply mean that any lib built-on top of Ruby's current meta-
programming constructs is going to be much slower (and less robust)
than something built-in to Ruby itself, basically because method
composition operates at such a low-level.

T.

Robert Dober

9/8/2007 6:17:00 AM

On 9/7/07, Trans <transfire@gmail.com> wrote:
>
> > > 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?
>
> No no. I simply mean that any lib built-on top of Ruby's current meta-
> programming constructs is going to be much slower (and less robust)
> than something built-in to Ruby itself, basically because method
> composition operates at such a low-level.
>
Hmm maybe yes, the VM could simply recompile the method, OTOH if Ruby2
will give us the ability we could recompile the method ourselves as we
could e.g. in Squeak.

Cheers
Robert
> T.
>
>
>

--
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

comp.lang.ruby

Re: before, after and around Ruby 1.9

Trans

Robert Dober

Robert Dober

Trans

Robert Dober

Trans

Robert Dober

x Login to ForumsZone