As we’re still pre-2.0, and talking about pre and post, I thought I’d
throw in a bit of possible syntax for this that occurred to me, namely
this:
class C
def x
puts "how are you?"
end
pre x
puts "hello"
end
post x
puts "goodbye"
end
end
It’s possible that there are problems with doing it this way that I’m
not seeing, but personally I like the way it looks better than
def x:pre
which to me has a bit of a “spliced onto the language” feel (which
perhaps it is, but it would still be nice to avoid that feel I
like the simplicity and symmetry of separate def/pre/post.
which to me has a bit of a “spliced onto the language” feel (which
perhaps it is, but it would still be nice to avoid that feel I
like the simplicity and symmetry of separate def/pre/post.
You’ve got my vote for looks. But it means two extra keywords which breaks
extra stuff, and I’m not fond of that. But 2.0 is allowed to break stuff so my vote stands.
Sorry David, your a little late to make claims on that one. If you read my AOP
RCR (which by the way I think I’ve plugged like six times now) you would
notice that I offer:
wrap w
super
print “W”
end
as a backup alternative to my primary proposal, which I belive to be a far
superior:
class C
def x
puts “how are you?”
end
def x
puts "hello"
super
puts "goodbye"
end
end
Before anyone looks at this and crys “foul!”, read the dang RCR.
On Friday 28 November 2003 03:32 am, David A. Black wrote:
As we’re still pre-2.0, and talking about pre and post, I thought I’d
throw in a bit of possible syntax for this that occurred to me, namely
this:
class C
def x
puts “how are you?”
end
pre x
puts "hello"
end
post x
puts "goodbye"
end
end
It’s possible that there are problems with doing it this way that I’m
not seeing, but personally I like the way it looks better than
def x:pre
which to me has a bit of a “spliced onto the language” feel (which
perhaps it is, but it would still be nice to avoid that feel I
like the simplicity and symmetry of separate def/pre/post.
As we’re still pre-2.0, and talking about pre and post, I thought I’d
throw in a bit of possible syntax for this that occurred to me, namely
this:
class C
def x
puts “how are you?”
end
pre x
puts “hello”
end
post x
puts “goodbye”
end
end
It’s possible that there are problems with doing it this way that I’m
not seeing, but personally I like the way it looks better than
def x:pre
which to me has a bit of a “spliced onto the language” feel (which
perhaps it is, but it would still be nice to avoid that feel I
like the simplicity and symmetry of separate def/pre/post.
This is excellent. I hope there aren’t any gotchas that nobody has
thought of. You’re right about the “splicing” thing. This feels a lot
more like it’s supposed to be a part of Ruby.
I much prefer the foo:pre, foo:post way to this. Of course the first
time I saw this (apart from doing AspectJ work in Java) was in Lisp, and
what Matz proposed was lifted straight from Lisp. Using ‘pre’ and ‘post’
as equivalents of ‘def’ seems a bit of a hack, to me. I think the
foo:pre syntax is more explicit in expressing what you are trying to do
that this.
Joey
···
On 11/27/2003 10:47 PM, Chad Fowler wrote:
On Fri, 28 Nov 2003, David A. Black wrote:
class C
def x
puts “how are you?”
end
pre x
puts “hello”
end
post x
puts “goodbye”
end
end
It’s possible that there are problems with doing it this way that I’m
not seeing, but personally I like the way it looks better than
def x:pre
This is excellent. I hope there aren’t any gotchas that nobody has
thought of. You’re right about the “splicing” thing. This feels a lot
more like it’s supposed to be a part of Ruby.
–
Never trust a girl with your mother’s cow
never let your trousers go falling down in the green grass…
On Friday 28 November 2003 03:32 am, David A. Black wrote:
> As we’re still pre-2.0, and talking about pre and post, I thought I’d
> throw in a bit of possible syntax for this that occurred to me, namely
> this:
>
> class C
> def x
> puts “how are you?”
> end
>
> pre x
> puts “hello”
> end
>
> post x
> puts “goodbye”
> end
> end
>
> It’s possible that there are problems with doing it this way that I’m
> not seeing, but personally I like the way it looks better than
>
> def x:pre
>
> which to me has a bit of a “spliced onto the language” feel (which
> perhaps it is, but it would still be nice to avoid that feel I
> like the simplicity and symmetry of separate def/pre/post.
···
On Fri, 28 Nov 2003, T. Onoma wrote:
Sorry David, your a little late to make claims on that one. If you read my AOP
RCR (which by the way I think I’ve plugged like six times now) you would
notice that I offer:
I don’t see how these are the same idea. And, yes, I read the “dang” RCR.
In particular, your implicit method definition stacking looks like it
would very quickly lead to some unmanagable knots of code. When I look at
it, my mind thinks overwrite. The comparison to the usage of “super” in
inheritance seems like a serious stretch.
I fully understand what you are saying in the RCR, but I don’t think it
will make intuitive sense to Ruby users. I think pre, post, and wrap need
to be explicit (as matz has laid them out in his proposal). Additionally,
if we’re going to stack method definitions, that should be explicit too.
Inheritance, maybe only historically, is in my opinion a good place to
draw the line between implicit feature addition and replacement.
which to me has a bit of a “spliced onto the language” feel (which
perhaps it is, but it would still be nice to avoid that feel I
like the simplicity and symmetry of separate def/pre/post.
You’ve got my vote for looks. But it means two extra keywords which
breaks
extra stuff, and I’m not fond of that. But 2.0 is allowed to break stuff so my vote stands.
matz wrote:
That’s the point. Hooking method is a part of metaprogramming, which
should be handled with care, even in the future. x:*** are a good
signs for it.
Then how about introducing new keywords that are unlikely to break other
code?
def foo
def:pre foo
def:post foo
def:wrap foo
It’s visible significant enough to ring a bell and it doesn’t change the
method name, which IMHO better matches the semantics: this is a “def” of
an ordinary method, but the definition of a method wrapper.
I much prefer the foo:pre, foo:post way to this. Of course the first
time I saw this (apart from doing AspectJ work in Java) was in Lisp, and
what Matz proposed was lifted straight from Lisp. Using ‘pre’ and ‘post’
as equivalents of ‘def’ seems a bit of a hack, to me. I think the
foo:pre syntax is more explicit in expressing what you are trying to do
that this.
I only wish I had the skill to hack keywords into the language (On
second thought, maybe I don’t
It’s hard to say which of the two syntaxes is more explicit, since if
the one I suggested were adopted, then
pre x
would be the explicit way to do this (just as def is an explicit way
to define methods, etc.). def x:pre is more eye-catching or distinct,
I guess, but I imagine there might come a time when one said “Why do
pre and post have these distinct, eye-catching forms instead of being
normal keywords like def?” Hard to predict… it’s just something
that occurs to me.
I don’t see how these are the same idea. And, yes, I read the “dang” RCR.
HUH?
wrap
…
end
is nothing like?
pre
…
end
Doh! What was I thinking!? Well, I don’t care anyway. Obviously David is just
ignoring my comment. Nor any mention of my RCR. His loss.
In particular, your implicit method definition stacking looks like it
would very quickly lead to some unmanagable knots of code. When I look at
it, my mind thinks overwrite. The comparison to the usage of “super” in
inheritance seems like a serious stretch.
Stretch? That’s funny because singletons are essentially an implementation of
wraps, the concpet of which being the foundation of my proposal, and I don’t
here any body claiminging their unmanagable.
I fully understand what you are saying in the RCR, but I don’t think it
will make intuitive sense to Ruby users. I think pre, post, and wrap need
to be explicit (as matz has laid them out in his proposal). Additionally,
if we’re going to stack method definitions, that should be explicit too.
Inheritance, maybe only historically, is in my opinion a good place to
draw the line between implicit feature addition and replacement.
Suit yourself, draw a line. But I think your just further complicating the
language, which at this point could actually use some simplification. Sadly,
it seems like Ruby’s headed the way of Perl
-t0
···
On Friday 28 November 2003 05:09 am, Chad Fowler wrote:
Thanks for reading the RCR. I would have liked to known your thoughts prior
to my explication. For what am I to think? I’m having a discussion on the
topic and I’ve asked that others read it for the sake of that discussion. But
only one person has commented and that is Austin. So, as far as I can tell no
one has read it. Especially when David comes along and suggests “his” idea
about the keyword, which I’ve already made. Can you understand where I’m
coming from?
Sincerely,
-t0
···
On Friday 28 November 2003 05:09 am, Chad Fowler wrote:
I don’t see how these are the same idea. And, yes, I read the “dang” RCR.
You might be able to “predict” it by looking at the experiences of
other languages.
It obviously is subjective. I’m, 100% with Joey on this one. Since
it’s subjective, I won’t bother trying to explain why
Gavin
···
On Friday, November 28, 2003, 3:45:32 PM, David wrote:
Hi –
On Fri, 28 Nov 2003, Joey Gibson wrote:
I much prefer the foo:pre, foo:post way to this. […]
[…]
def x:pre is more eye-catching or distinct, I guess, but I imagine
there might come a time when one said “Why do pre and post have
these distinct, eye-catching forms instead of being normal keywords
like def?” Hard to predict… it’s just something that occurs to me.
Super-wrapping is wrapping the call to super within a method - basically,
inserting your wrapper function before the previous one in the chain instead
of appending afterward.
In other words, if the latest wrapper for method `foo’ looks like this:
def foo:wrap
pre_stuff
super
post_stuff
end
Then super-wrapping gives you the ability to add code after pre_stuff
but before super, or after super but before post_stuff, instead of limiting
you to either before pre_stuff or after post_stuff.
I do recommend that everyone interested in Rite design and/or AOP
read T Onoma’s RCR; it’s interesting, even though I’m not sure I agree with
the proposal.
-Mark
···
On Sat, Nov 29, 2003 at 04:15:24AM +0900, Hal Fulton wrote:
okay, i see how that can be useful. cool. these are quite a nit differnt from
wrap. they are only for monitoring purposes. limited but useful, and safe.
defpre
defpost
work for me. while the : is nice it strikes too much like a naming, especially
with the new hash notation on the way { a: 1 }.
-t0
···
On Friday 28 November 2003 08:44 pm, Jim Weirich wrote:
T. Onoma wrote:
but can anyone explain why we have pre and post if wrap does them both?
Pre and Post cannot effect the incoming parameters[1], nor can they
effect the return result. Wrap can do both.
So, pre/post are “safer” if you don’t want to change the semantics of
the base method (e.g. logging).
On Friday 28 November 2003 09:07 pm, Mark J. Reed wrote:
On Sat, Nov 29, 2003 at 04:15:24AM +0900, Hal Fulton wrote:
T. Onoma wrote:
and what about super wrapping?
Not sure what you mean.
Super-wrapping is wrapping the call to super within a method - basically,
inserting your wrapper function before the previous one in the chain
instead of appending afterward.
In other words, if the latest wrapper for method `foo’ looks like this:
def foo:wrap
pre_stuff
super
post_stuff
end
Then super-wrapping gives you the ability to add code after pre_stuff
but before super, or after super but before post_stuff, instead of limiting
you to either before pre_stuff or after post_stuff.
I do recommend that everyone interested in Rite design and/or AOP
read T Onoma’s RCR; it’s interesting, even though I’m not sure I agree with
the proposal.
I
I
I