Asp Forum - Re: pre/post question/idea

Peter

11/28/2003 3:03:00 AM

8 Answers

Robert Klemme

11/28/2003 9:32:00 AM

"Peter" <Peter.Vanbroekhoven@cs.kuleuven.ac.be> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0311280359580.3918-100000@merlin.cs.kuleuven.ac.be...
> > 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.

Kind regards

robert

T. Onoma

11/28/2003 10:23:00 AM

On Friday 28 November 2003 10:32 am, Robert Klemme wrote:

> Then how about introducing new keywords that are unlikely to break other
> code?
>
> def foo
> def:pre foo
> def:post foo
> def:wrap foo

Or just,

def foo
def_pre foo
def_post foo
def_wrap foo

but can anyone explain why we have pre and post if wrap does them both?

and what about super wrapping?

-t0

Hal E. Fulton

11/28/2003 7:15:00 PM

T. Onoma wrote:
> but can anyone explain why we have pre and post if wrap does them both?

I asked that, too. But after thinking about it, I decided it is
probably better this way.

If everything were "wrap" then you would have to look at the
method body to see whether it was adding code before, after,
or both.

With pre and post, you know where it's adding code without
looking beyond the "def" line.

> and what about super wrapping?

Not sure what you mean.

Hal

Jim Weirich

11/28/2003 7:44:00 PM

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

--
-- Jim Weirich jweirich@one.net http://onest...
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

[1] Well actually, I suppose they can effect the parameters if they call
a method with a side effect method on the parameters.

Mark J. Reed

11/28/2003 8:03:00 PM

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.

-Mark

T. Onoma

11/28/2003 8:30:00 PM

On Friday 28 November 2003 08:15 pm, Hal Fulton wrote:
> T. Onoma wrote:
> > but can anyone explain why we have pre and post if wrap does them both?
>
> I asked that, too. But after thinking about it, I decided it is
> probably better this way.
>
> If everything were "wrap" then you would have to look at the
> method body to see whether it was adding code before, after,
> or both.
>
> With pre and post, you know where it's adding code without
> looking beyond the "def" line.

okay. no biggy either way. just seems like less for ruby to parse if we don't
really need them.

> > and what about super wrapping?
>
> Not sure what you mean.

ruby-talk:86487

> Hal

T. Onoma

11/28/2003 8:39:00 PM

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

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

T. Onoma

11/28/2003 8:50:00 PM

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.

*sigh*.... Thank you, Mark.

comp.lang.ruby

Re: pre/post question/idea

Peter

Robert Klemme

T. Onoma

Hal E. Fulton

Jim Weirich

Mark J. Reed

T. Onoma

T. Onoma

T. Onoma

x Login to ForumsZone