On Sat, Feb 28, 2004 at 11:56:52AM -0800, Gregor N. Purdy wrote:
: Smylers --
:
: I think the claim in E7 is stronger, that not only does the string match
: the identifier pattern, but that it is a 'valid' (known, declared)
: identifier. Else, what would be the point of saying both:
:
: * "contains a valid identifier", and
: * "check the validity before the program starts"
:
: But, since E7 doesn't come right out and say it, I'm asking for
: clarification. Still could be that you are right and there is nothing
: to see here, though...
No, they don't need to be declared identifiers, or there'd be no point
in putting the colon in front to autoquote them. I think Damian's
point is that, at least for subroutines that you've seen the signature
of already, you could check the idents against the parameter list and
catch typos. Possibly such a check would complain about the options
being passed to form(), and form() would have to be declared with
something saying that's okay. (In general, declaring a *% parameter
would make random options okay, but form() can't do that because it
relies on the ordering of its *@ values.)
Checking option names against methods is more problematic since they
do very late binding. If an application has declared some or all of
its classes closed, however, the compiler could conceivably be able
to evaluate all possible methods that a given typed object could call,
and issue warnings on mismatches. But I doubt we'll see such a thing
in 6.0.0.
There are similar problems with knowing whether something is called in
scalar or list context for methods. If you say
$obj.method($a,@b,%c)
it doesn't matter, because under the hood @b and %c are always passed
by reference even in list context, and the decision on how to treat
@b and %c can be deferred till after the method is dispatched, when
parameters are bound. But if you say
$obj.method($a,@b,%c,d())
then we don't really know what context d() is in until the dispatch,
and that might be too late to call d(). But d() might really want to
know its context. There are several ways to fudge this, but they're
all forms of cheating, except maybe the brute force way of passing
in d() as a closure {d()}. That would get d()'s scoping right,
except that you'd probably want to lie to it about the fact that
we're already down in .method's parameter binding code. So I guess
that's cheating too...
Larry
