T. Onoma
11/30/2003 10:19:00 PM
On Sunday 30 November 2003 09:39 pm, Peter wrote:
> Never mind, I think I've answered my own question in meanwhile. pre and
> post can't alter the result of the method calls, which makes them ideal
> for the "meta-tasks" (extrinsic). def can alter the semantics of a method
> which makes them ideal for the intrinsic part. But it might sometimes be
> convenient to use def even for something extrinsic because of something
> like this:
>
> def foo(*args)
> # set a here, do other stuff not affecting the super call
> result = super
> # use a here, do other stuff not affecting the result
> result
> end
You're absolutely right. Hmm...Granted this is acting in accordance to an
intrinsic wrap, buit it's not gaurenteed. So this is fine, but if foo is
later redefined this wrap will be flushed (at least IMHO it should be). But
we need to solve the problem you present., so either pre and post must be
considered essentially connected in scope with access to the same vars, which
seems rather odd, or we can just have an intrinstic wrap defintion like:
wrap foo(*args)
# set a here, do other stuff not affecting the super call
result = psudeo_super
# use a here, do other stuff not affecting the result
end
Then we don't need pre or post. I suppose if no "psuedo_super" is given it
would be assumed to be like a pre? I'm not sure. What do you think?
> I think we misunderstood each other again, but correct me if I'm wrong. I
> think you thought I meant adding the same aspect to methods in different
> classes, right? I meant adding different advice to methods in different
> classes but share the same "private, yet global vars".
Your right. Sorry. But I do think sime of the same basic methods apply. Not
sure. I guess I need some examples to really be able to consider.
> > method(eat).to_s.tag =~ /consuming/
> >
> > So I don't know if we really need to do beyond a single indicator symbol.
>
> I'm short-sighted as usual, you're right :-)
Ha! You should see how thick *my* glasses are! :-)
> This to me is just the same as doing:
>
> class A
> def foo
> print "foo"
> end
> end
>
> class A_c < A
> def foo
> print "("
> super
> print ")"
> end
> end
>
> class A_c
> def foo
> print "["
> super
> print "]"
> end
> end
>
> c = A_c.new
>
> c.foo # [foo]
>
> I admit, this makes the second foo look like a wrapping and the third like
> a redefinition.
I hold my tounge ;-)
> But this is consistent with the idea that each object gets
> its own singleton class (though in the implementation it is only created
> when necessary), and defining object.foo is like adding the method to
> object's singleton class. The Pickaxe doesn't say it this way, but instead
> goes into detail of implementation. But that was my way of thinking about
> it on an abstract level that is consistent with the implementation, and
> there was no wrapper idea involved. That's what I tried to say. But if you
> really look at it as some wrapping mechanism, your new implementation
> makes more sense.
I think you're right on. My implementation, instead, just adds more of the
same:
class A
def foo
print "foo"
end
end
class A_c < A
def foo
print "("
super
print ")"
end
end
class A_cc < A_c
def foo
print "["
super
print "]"
end
end
c = A_cc.new
c.foo # [(foo)]
-t0