On Wed, Jun 08, 2005 at 09:21:38PM +0300, Gaal Yahas wrote:
: A06 and S06 are in disagreement about the "caller" builtin, and I need
: help understanding either one.
:
: A06 [plus updates] stipulates this signature for caller:
:
: multi *caller (?$where = &?CALLER::SUB, Int +$skip = 0, Str +$label)
: returns CallerContext { ... }
:
: In S06 it's (I infer):
:
: multi *caller (Class ?$kind = Code, Int +$skip = 0, Str +$label) { ... }
:
: I'm assuming S06 is the more correct; A06 said that $where "says where
: to stop when scanning up the call stack" but it only makes sense to me
: if it says where to *start* scanning.
That's because stop and start are the same place when $skip is 0.
: In the Synopsis version, does $kind imply a filtering condition on *all*
: stack frames it encounters, or just on where the first one is? That is,
: if we have this contrived example:
:
: sub p() { caller(Sub, :skip<1>).sub.say }
: method a() { p() }
: sub b() { a() }
: method c() { b() }
: sub d() { c() }
:
: Does this start looking upwards for a Sub, find &b, skip one caller and
: print "c"? Or does it find &b, skip one *Sub*, and print "d"?
:
: I'm not sure how this selection mechanism is meant to be used.
The skip is meant to be applied after filtration. Don't filter out
things you want to see later, in other words.
: Other questions:
:
: - A06 stipulates "CallerContext" but to be more in line with the latest
: S29 draft, we've used "Control::Caller". Okay to use that?
Fine by me.
: - AES does not enumerate the complete member set. We can use that now :)
Um. That's something I wouldn't mind delegating to whoever is slogging
it out on the ground.
: - S06 stipulates the method for sub name is "sub". I find "subname" to
: be more appealing. Okay to use that?
Depends on whether it's really the name or the sub object.
: - Perhaps caller.sub could be made to return the code ref itself, which
: given introspective capabilities can be a fun thing. At the very
: least, we want to be able to call .arity on the result of a caller,
: but if that, why not also get the signature information, and while
: we're at it -- the actual runtime parameters (if still available, and
: if this doesn't turn out too hard to implement)?
That's the direction we're going with &?SUB and $?SUBNAME, so I don't
see why it couldn't apply here too.
: S06's "want" is much simpler than A06's. Can it for now be considered
: complete? (I'm asking because A06 links "want" intimately to "caller"
: and that appears to no longer be the case.)
It would be nice if the interfaces were similar where they try to do
similar things.
But then, it might be nice to copy over the :nth($n) interface from
pattern matching too, somehow or other. Right now our selectors don't
have a way to generalize that. You almost want to be able to say
something like caller(3rd(Sub)), which causes ~~ to match Sub, but
only on the third thing that could be construed as a Sub, presuming
~~ is treating the other argument as some kind of iterator. But up
till now we've been treating such iterators as external to ~~, with
the args matched one at a time. One could imagine seeing things like:
given =$IN {
when 1st(/foo/) {...}
when 2nd(/bar/) {...}
when 3rd(/baz/) {...}
}
but the semantics of such a construct are more than somewhat problematic.
Larry
