Method wrapping

[T. Onoma]

Hi,

In message "Re: Method wrapping"

|> They remain in place.
|
|I don't think that's a desirable behavior. See previous post.

Which one? We have too many "previous" posts here.

the "right before this one" kind of previous ;-)

do i post too much?

-t0

 

[Gavin Sinclair]

Oh, and Gavin,

Happy Thanksgiving

Thanks, but there ain't no thanksgiving down here!

 

[T. Onoma]

Right?

Nope. With your example, A#riot no longer calls back to X. This is not what I
am talking to. What I mean is that in the second class 'A', def doesn't do
the same kind of thing as in in third class 'B < A', even though the *syntax
is exactly the same*. You only know that they do something different because
you look up to top of class and see '< A', then you have to say "Oh, that
means it all works different."

class A < X
def riot
print "P"
end
end

class A
def riot # this redefines
super
print "R"
end
end

class B < A # this changes how def works if method is in superclass
def riot
super # this wraps
print "W"
end
end

|It is important to understand that Ruby already has a wrapping facility
| using subclasses. And singletons act similiarly. So it would be more
| consistent to naturally extend that to in-class wraps. We can do this
| without having to add special syntax sugar (the colon).

But how? I don't see concrete syntax you are saying.

Read the following to fully understand and get syntax:

http://www.rubygarden.org/ruby?AspectOrientedRuby

But if you don't have the time right now here is a quick full example. Notice
that the defs could be in superclass or not. It makes no difference to how
wrapping works.

def w # this could be in superclass
print "W"
end

def w # and so could this
print "Y"
super
print "Y"
end

def w
print "["
superwrap
print "("
super
print ")"
end
print "]"
end

w; puts # => [Y(W)Y]

This is join-point map to help you understand above:

def a_method
# <- pre join-point
print "<"
# <- super-pre join-point
super
# <- super-post join-point
print ">"
# <- post join-point
end

Note that, if you need to BOTH redefine AND access superclass method, then you
would use redef, not def. In all other ways, this is backward compatible with
Ruby1. Please ask me any questions if something dosen't make sense.

Happy Thanksgiving, Matz,
-t0

(Do you have Thanksgiving in Japan?)

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Method wrapping"

|> Which one? We have too many "previous" posts here.
|
|the "right before this one" kind of previous ;-)
|
|do i post too much?

No. But I prefer identity by X-Mail-Count (for example, I'm replying
to [ruby-talk:86484]).

matz.

 

[T. Onoma]

Of course, I was referreing to the interface of the implementation. Sorry,
for not being more specific.

Actually I have rethought this. Wrappers do depend on the implementation b/c
their proper functionality depends on *what* is returned, not just what
*kind*. They may not raise an error if the kinds are the same, but that
doesn't mean they work right. So my original wording was more correct.

-t0

 

[Charles Hixson]

Hi,

In message "Re: Method wrapping"

|> Which one? We have too many "previous" posts here.
|
|the "right before this one" kind of previous ;-)
|
|do i post too much?

No. But I prefer identity by X-Mail-Count (for example, I'm replying
to [ruby-talk:86484]).

matz.

FWIW,
Reading the mail list on Mozilla, I don't even *see* the X-Mail-Count
unless I turn on all headers, and then I get so many headers that I
can't see the messages. This may be a criticism of Mozilla, but it does
make it difficult to refer to the X-Mail-Count.

 

[Jim Weirich]

Actually I have rethought this. Wrappers do depend on the implementation b/c
their proper functionality depends on *what* is returned, not just what
*kind*. They may not raise an error if the kinds are the same, but that
doesn't mean they work right. So my original wording was more correct.

The distinction between *what* and *kind* alludes me for the moment.
However, I would tend to suspect that a wrapper depends upon the primary
method in the same way client software depends upon the methods it
calls. In other words, they depend upon the arguments, return value and
semantics (as defined by a DbC style contract), but not upon actual
implementation.

I would suspect that most method replacements would honor the same
argument lists, return types and basic semantics. Otherwise replacing a
method would cause *everyone* who calls that method to be modified, not
just the wrapper methods.

 

[Paul Brannan]

FWIW,
Reading the mail list on Mozilla, I don't even *see* the X-Mail-Count
unless I turn on all headers, and then I get so many headers that I
can't see the messages. This may be a criticism of Mozilla, but it does
make it difficult to refer to the X-Mail-Count.

We used to put it in the subject (i.e. Subect: Re: [ruby-talk:12345]
Method wrapping), but this caused problems with threading in some mail
readers, and most people agreed it was better to turn it off. We've
still retained the same naming scheme for mailing list posts, however.

Paul

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Method wrapping"

|Reading the mail list on Mozilla, I don't even *see* the X-Mail-Count
|unless I turn on all headers, and then I get so many headers that I
|can't see the messages. This may be a criticism of Mozilla, but it does
|make it difficult to refer to the X-Mail-Count.

I do understand the situation, it's same for me. But still I need
something to identify the message from bunch of posts. As far as I
know, X-Mail-Count is the best identifier.

matz.