On Tue, Apr 09, 2002 at 09:56:02PM +0100, Piers Cawley wrote:
> Larry Wall <[EMAIL PROTECTED]> writes:
>
> > We're talking about how to make .foo mean self.foo regardless of the
> > current topic.
>
> Are we? I was looking for a way to unambgiously access the current
> object in such a way that topicalizers would still work...
I think we were talking about both.
Okay, now that thith hath had a chanth to thteep in my brain for a day
or tho... Here's a twist to another perspective:
The thing with this "invocant" is, you're essentially creating another
$_. It's an accessible named thing that acts as a noun and automatically
receives a value in a particular context. It may be implemented as a
macro, but will be perceived as a variable, another named alias to the
value, since it can be used in all the same contexts as a "full"
variable. Because of this, I'd like to see it keep the sigil, not by
choice, but by requirement:
use invocant "self";
...
method ical {
$self.method_call();
...
}
It's similar to the old concept of topic, before topic and $_ were
unified. Maybe we now have "invocantalizers"? ;)
Some of the issues:
- The .method_call() syntax is not nearly as appealing if you can't use
it consistently,
but,
- It is desirable, from a language learning/use perspective, for
.some_call() to always act the same within a C<given> when the topic
is an object, whether the construct is within a method or not (or at
least default to acting the same).
- The natural question, once you realize Perl is holding this
automatically generated value for you (which seems almost, but not
quiet, identical to $_), is "Why can't I default to it?",
but,
- One of the reasons for merging $_ and topic was to avoid the confusion
of multiple defaults (and to avoid deprecating $_ to "the default
default"). Invocants might add that complexity back.
I see two directions the solution could go in. Direction 1 is "if you
don't like it, lump it". If you're going to need to access an outer
topic within a nested topicalizer, you should define a named
variable/parameter ("method icial ($self:..."). This is the path we've
taken with other nested topicalizers.
Direction 2 moves into the more exciting but scarier realm of alternate
defaults. I would suggest that if we do add a) the ability to
automatically populate variables (or macro accessed values) other than
$_ and b) the ability to default to these variables (or macro accessed
values), that we separate the two concepts, either by using two separate
pragmas, or by making the "invocant as default" an option on the
invocant pragma. I don't think defining a blank "" invocant name, or
leaving off the name is ostentatious enough to do justice to the drastic
change of altering the topic structure within the scope of all methods
in the class (this is related to the linguistic principle of "given vs.
new information", new information is typically "marked", more
prominent). Here are a few possibilities:
use invocant "self";
use method_default "self";
use invocant "self" is method_default;
my $self is invocant is method_default;
None of these is quite satisfying. All have associated problems: the
first because the "method_default" pragma couldn't quite stand alone,
the second because of the non-standard use of C<is>, the third because
you don't quite want to declare a variable, just specify a default.
Hmm... possibly:
use invocant $self is method_default;
Which solves the first problem, by being a single statement, the second
problem by making the "is method_default" a property of the variable (or
more literally, a property that is pre-defined to be associated to the
variable when it is instantiated in a method), and totally bypasses the
third problem.
The choice of "method_default" is intended to specify that the unique
behaviour only affects .method_call() defaults, not the hoi polloi,
garden-variety defaulting constructs, but a better name could be found.
Allison
