Method wrapper question (was "stereotyping (was ...))

[Christoph]

ts wrote:
...

> G> Well, I'm not sure what I want in this case. Wrapping
> methods is a
> G> great idea to satisfy a common idiom. I think it does seem a bit
> G> wrong not to allow multiple wrappers, though. The idiom
> as it stands
>
> Perhaps in this case, you can also have multiple def in the
> same class :-)
>
> G> What method are you talking about?
>
> module B
> def a:pre
> end
> end
>
> class A
> include B
>
> def a:pre
> end
>
> def a
> end
> end

Well technically they do not live in the same class,
since the a:pre provided by B's inclusion lives in
A's B-proxy class and not in A itself.


/Christoph

[ts]

>>>>> "C" == Christoph <chr_mail@gmx.net> writes:

C> Well technically they do not live in the same class,
C> since the a:pre provided by B's inclusion lives in
C> A's B-proxy class and not in A itself.

Yes, and this is why I prefer this scheme to

class A
def a:pre
end

def a:pre
end

def a
end
end


Guy Decoux

[Christoph]

ts wrote:
...

> Yes, and this is why I prefer this scheme to
>
> class A
> def a:pre
> end
>
> def a:pre
> end
>
> def a
> end
> end

Agreed 100% - I see no reason for allowing several hooks
in the same class.

/Christoph

[Christoph]

ts wrote:
...

> Yes, and this is why I prefer this scheme to
>
> class A
> def a:pre
> end
>
> def a:pre
> end
>
> def a
> end
> end

Agreed 100% - I see no reason for allowing several hooks in the same class.

/Christoph

[Michael Neumann]

On Sat, Nov 22, 2003 at 11:15:04PM +0900, Christoph wrote:

> ts wrote:
> ...

> > Yes, and this is why I prefer this scheme to
> >
> > class A
> > def a:pre
> > end
> >
> > def a:pre
> > end
> >
> > def a
> > end
> > end

>
> Agreed 100% - I see no reason for allowing several hooks
> in the same class.

I could see a reason. Imagine the following scenario (monitors):

class A

def a:pre
# my own pre-wrapper
end

synchronize :a # defines a:pre and a:post

def a
# critical section
end

end

The implementation of sychronize has to do ugly method aliasing stuff,
and depending on the order you define your own a:pre (e.g. putting the
synchronize before it), the monitor-code gets overwritten.

Regards,

Michael

[Gavin Sinclair]

On Sunday, November 23, 2003, 1:15:04 AM, Christoph wrote:

> ts wrote:
> ...

>> Yes, and this is why I prefer this scheme to
>>
>> class A
>> def a:pre
>> end
>>
>> def a:pre
>> end
>>
>> def a
>> end
>> end

> Agreed 100% - I see no reason for allowing several hooks
> in the same class.

What difference does it make? Import a method or define it yourself -
what's the big deal?

What about:

require 'example' # Includes class A, which defines A#foo:pre,
# but I don't know that, because I just use
# the library; I didn't write the damn thing.
# I know about A#foo, though, because it's a
# really important method I read about in the
# RDoc.

# Hmmm.... I just want to log calls to A.foo, because something
# funny seems to be going on in there.

class A
def foo:pre(*args)
puts "Calling A#foo(#{*args.join(',')})"
end
end


So are you saying I shouldn't do that? Or the author of class A
shouldn't define foo:pre, or that I should write a module defining
A#foo:pre and include that in A?

Gavin

[ts]

>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:

G> What difference does it make? Import a method or define it yourself -
G> what's the big deal?

OK, but I want to do the same with normal methods

G> What about:

G> require 'example' # Includes class A, which defines A#foo:pre,

# and define a private method a

G> # but I don't know that, because I just use
G> # the library; I didn't write the damn thing.
G> # I know about A#foo, though, because it's a
G> # really important method I read about in the
G> # RDoc.

G> # Hmmm.... I just want to log calls to A.foo, because something
G> # funny seems to be going on in there.

# I just want to define a method a


G> class A
G> def foo:pre(*args)
G> puts "Calling A#foo(#{*args.join(',')})"
G> end

def a
puts "a"
end

G> end


G> So are you saying I shouldn't do that? Or the author of class A
G> shouldn't define foo:pre, or that I should write a module defining
G> A#foo:pre and include that in A?

You have the same problem actually with methods, perhaps you just don't
see it


Guy Decoux

[ts]

>>>>> "M" == Michael Neumann <mneumann@ntecs.de> writes:

M> The implementation of sychronize has to do ugly method aliasing stuff,
M> and depending on the order you define your own a:pre (e.g. putting the
M> synchronize before it), the monitor-code gets overwritten.

and the result is different if you call synchronize before or after
a:pre : you have the same problem.


Guy Decoux

p.s. : look at Allegro-CL

[Gavin Sinclair]

On Sunday, November 23, 2003, 1:56:57 AM, ts wrote:

>>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:

G>> What difference does it make? Import a method or define it yourself -
G>> what's the big deal?

> OK, but I want to do the same with normal methods

>> [...]

> You have the same problem actually with methods, perhaps you just don't
> see it

You're right, I don't see it. A wrapper around a method is not a
method.

I suppose it is possible that you could implement Ruby so that this
behaviour ensues:

class Example
def a; print "X"; end
def a; print "Y"; end
end

Example.new.a # -> "XY"

You'd have some potential issues with argument lists and return types,
but if people wanted this behaviour, it would be technically possible
to give it to them. People wouldn't want it, though.

It is equally technically possible to allow multiple method wrappers.
The cultural resistence is, I predict, less, as we wrap methods all
the time with ugly aliasing tricks, and there's no preventing
multi-wrapping there.

So what's the conclusion going to be?

And what am I missing?

Gavin

[ts]

>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:

G> And what am I missing?

What do you use : CLOS style, BETA style or Allegro style ?

Guy Decoux

[Gavin Sinclair]

On Sunday, November 23, 2003, 2:18:43 AM, ts wrote:

>>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:

G>> And what am I missing?

> What do you use : CLOS style, BETA style or Allegro style ?

I use Ruby style. What's that got to do with it?

Gavin

[ts]

>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:

G> On Sunday, November 23, 2003, 2:18:43 AM, ts wrote:

>>>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:

G> And what am I missing?

>> What do you use : CLOS style, BETA style or Allegro style ?

G> I use Ruby style.

define it.

G> What's that got to do with it?

CLOS, BETA, Allegro = 3 languages with method combinations and 3 different
methods to call :pre, :post, ...


Guy Decoux

[Christoph]

Gavin Sinclair wrote:
...

> G>> And what am I missing?
>

> > What do you use : CLOS style, BETA style or Allegro style ?

>
> I use Ruby style. What's that got to do with it?

Ruby style is still evolving and thus it makes plenty of
sense to look at already existing implementations.

/Christoph

[Michael Neumann]

On Sun, Nov 23, 2003 at 12:10:35AM +0900, Gavin Sinclair wrote:

> On Sunday, November 23, 2003, 1:56:57 AM, ts wrote:
>

> >>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:

>
> G>> What difference does it make? Import a method or define it yourself -
> G>> what's the big deal?
>

> > OK, but I want to do the same with normal methods

>

> >> [...]

>

> > You have the same problem actually with methods, perhaps you just don't
> > see it

>
>
> You're right, I don't see it. A wrapper around a method is not a
> method.
>
> I suppose it is possible that you could implement Ruby so that this
> behaviour ensues:
>
> class Example
> def a; print "X"; end
> def a; print "Y"; end
> end
>
> Example.new.a # -> "XY"
>
> You'd have some potential issues with argument lists and return types,
> but if people wanted this behaviour, it would be technically possible
> to give it to them. People wouldn't want it, though.

A big win would be a "prior" or "last_method" statement, similar to
"super", but which calls the first "a" in the upper example (instead of
the "a" of the superclass).

But that would mean that a class has to store multiple methods for each
method name, which might come out as a performance or memory problem.

> It is equally technically possible to allow multiple method wrappers.
> The cultural resistence is, I predict, less, as we wrap methods all
> the time with ugly aliasing tricks, and there's no preventing
> multi-wrapping there.

It's easier to break automatic wrapping by undefining a method, than it
is to allow safe wrapping. But for normal methods, it's nonsense.

class Example
def a:pre; ... end

undef_method a:pre # breaks multi-wrapping

def a:pre; ... end
end

Anyway, I'd prefer the "prior" or "last_method" way.


Regards,

Michael

[Michael Neumann]

On Sun, Nov 23, 2003 at 12:01:34AM +0900, ts wrote:

> p.s. : look at Allegro-CL

Wow. NFS server written in Allegro-CL. Must be damn fast.


Regards,

Michael

[T. Onoma]

On Saturday 22 November 2003 03:15 pm, Christoph wrote:

> Agreed 100% - I see no reason for allowing several hooks
> in the same class.

Except that it means more work for interpreter to enforce rule of not allowing
it. Would you say the same thing about this?

class WhatDoIDo

def dothis
print "Nope"
end

def dothis
print "Yep"
end

end

[Ryan Pavlik]

On Sat, 22 Nov 2003 23:33:57 +0900
"Christoph" <chr_mail@gmx.net> wrote:

> ts wrote:
> ...

> > Yes, and this is why I prefer this scheme to
> >
> > class A
> > def a:pre
> > end
> >
> > def a:pre
> > end
> >
> > def a
> > end
> > end

>
> Agreed 100% - I see no reason for allowing several hooks in the same class.
>
> /Christoph
>

Hmm, actually, there are a lot of good reasons for allowing multiple
hooks in the same class. This is, AFAIK, the point of having hooks at
all... so many people can hook into them.

For instance, you may add a method:pre hook to check some parameter
values, make sure they're in range. You may include a package which
adds a :pre hook to add permissions. Etc.

If you can only have one hook, what's the difference between doing
this:

class Foo
def bar:pre
# pre stuff
end

def bar
# body stuff
end
end


and doing this:

class Foo
def bar
# pre stuff
# body stuff
end
end

or even this:

class Foo
def bar_pre
# pre stuff
end

def bar
bar_pre
# body stuff
end
end

To answer the question of order, it can either be configurable (I
think CLOS allows this) or simply "stack order" (latest defined :pre
goes first, latest defined :post goes last, etc.).

--
Ryan Pavlik <rpav@mephle.com>

"I wish I had arachna-powers. I would dispense death
from the skies." - 8BT

[T. Onoma]

After some exhaustive research and endless hours of thought I have put
together a page at RiteSuggestions about Aspect Oriented Programming (AOP)
for Ruby. (AOP is the overall term for programming with join-points which is
what :pre, :post and :wrap represent.) Have a look at.

[url]http://www.rubygarden.org/ruby?AspectOrientedRuby[/url]

As always, typo fixes and comments are welcome.

-t0

On Sunday 23 November 2003 09:02 am, Ryan Pavlik wrote:

> On Sat, 22 Nov 2003 23:33:57 +0900
>
> "Christoph" <chr_mail@gmx.net> wrote:

> > ts wrote:
> > ...
> >

> > > Yes, and this is why I prefer this scheme to
> > >
> > > class A
> > > def a:pre
> > > end
> > >
> > > def a:pre
> > > end
> > >
> > > def a
> > > end
> > > end

> >
> > Agreed 100% - I see no reason for allowing several hooks in the same
> > class.
> >
> > /Christoph

>
> Hmm, actually, there are a lot of good reasons for allowing multiple
> hooks in the same class. This is, AFAIK, the point of having hooks at
> all... so many people can hook into them.
>
> For instance, you may add a method:pre hook to check some parameter
> values, make sure they're in range. You may include a package which
> adds a :pre hook to add permissions. Etc.
>
> If you can only have one hook, what's the difference between doing
> this:
>
> class Foo
> def bar:pre
> # pre stuff
> end
>
> def bar
> # body stuff
> end
> end
>
>
> and doing this:
>
> class Foo
> def bar
> # pre stuff
> # body stuff
> end
> end
>
> or even this:
>
> class Foo
> def bar_pre
> # pre stuff
> end
>
> def bar
> bar_pre
> # body stuff
> end
> end
>
> To answer the question of order, it can either be configurable (I
> think CLOS allows this) or simply "stack order" (latest defined :pre
> goes first, latest defined :post goes last, etc.).

[Christoph]

> -----Original Message-----

Ryan Pavlik wrote:
...

>
> Hmm, actually, there are a lot of good reasons for allowing
> multiple hooks in the same class. This is, AFAIK, the point
> of having hooks at all... so many people can hook into them.
>
> For instance, you may add a method:pre hook to check some
> parameter values, make sure they're in range. You may
> include a package which adds a :pre hook to add permissions. Etc.
>
> If you can only have one hook, what's the difference between doing
> this:
>
> class Foo
> def bar:pre
> # pre stuff
> end
>
> def bar
> # body stuff
> end
> end
>
>
> and doing this:
>
> class Foo
> def bar
> # pre stuff
> # body stuff
> end
> end
>
> or even this:
>
> class Foo
> def bar_pre
> # pre stuff
> end
>
> def bar
> bar_pre
> # body stuff
> end
> end
>
> To answer the question of order, it can either be
> configurable (I think CLOS allows this) or simply "stack
> order" (latest defined :pre goes first, latest defined :post
> goes last, etc.).

Not to allow several hooks still leaves open adding hooks
defined in ancestors Classes (that includes Proxy Module
Inclusion classes). The latter possibility pretty much mimic
CLOS "stack order" - see Guy's suggestion of including
wrapper-method Modules.

Personally I think this scheme is simpler and much easier to
implement compared to allowing multiple hooks that need
to be managed in some ways (each method needs to carry
around a manageable list of it's hook-methods). I can see
that this might come in handy occasionally but it does not
add enough (for me) to justify the added complexities of this
scheme.

On the other hand I am not that strongly opinionated about this ...
the addition of hooks in any form is certainly a great addition.


/Christoph