Re: Unary dot and custom control
On Mon, Sep 20, 2004 at 07:25:14AM -0600, Luke Palmer wrote:
: Perl 6 is making it easier to define custom block constructs like this
: one. I worry about:
:
: method foo () {
: preserve {
: .bar;
: }
: }
:
: This one's a tad more subtle. Normally preserve's block would be 0-ary.
: But in this case it's unary, since it implicitly references $_.
:
: Is there a way to declare preserve so that its block will always be
: parsed 0-ary? if is certainly able to do this (consider the above
: example with s/preserve/if $baz/).
Such a block is parsed as 1-ary, but with an implicit argument that
defaults to the caller's $_, something like:
preserve sub ($_ = $CALLER::_) {
.bar;
}
Then it effectively becomes a run-time decision by preserve whether
to treat it as 0-ary or 1-ary.
Larry
Re: Unary dot
On Tue, Apr 16, 2002 at 09:29:21AM -0400, Miko O'Sullivan wrote: Wouldn't Know a Tagmemic if it Bit Him on the Parse Ooh, can I steal that as a title? (Though I'll s/Tagmemic/Tagmeme/.) I like it! :) Allison
Re: Unary dot
On Mon, Apr 15, 2002 at 07:24:13PM -0700, Larry Wall wrote:
So the main reason that objects can function as hashes is so that the
user can poke an object into an interface expecting a hash and have it
make sense, to the extent that the object is willing to be viewed like
that.
AKA the uniform access principle.
This was something that I was very keen to exploit in the Template Toolkit
where foo.bar is interpreted as Do(t) The Right Thing to access the
'bar' part of 'foo', be it the 'bar' key in the 'foo' hash or the 'bar'
method of the 'foo' object. The result is, of course, that you can use
a hash of static data one day (great for mocking up web pages for example)
and later upgrade it to an object which fetches/generates data on demand
(e.g. from a database) when you put your pages into production.
Alas, I also designed a flaw into the system by introducing virtual
methods that TT automatically applies onto various data types, equivalent
to various Perl functions, e.g. somehash.keys or somelist.size. As
convenient as this is, the problem lies in the fact that you can't
differentiate somehash.keys between the Perl equivalents of Ckeys %$hash
or C$hash-{keys}.
So my thought for version 3 of TT is to introduce somehash.{keys} as
a syntax to mean only the 'keys' key/method of the 'foo' hash/object
but *NOT* the 'keys' virtual method and to leave somehash.keys resolving
to the virtual method as it currently does.
Am I right in thinking that this would then be (roughly) consistent with
the Perl 6 syntax?
e.g.
TT3 Perl 6 Perl 5 (hash) Perl 5 (obj)
foo.keys $foo.keys keys %$foo $foo-keys()
foo.{keys} $foo.{keys} $foo-{keys} $foo-keys()
Hang on, now I'm a little confused - I thought that hashes were supposed
to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
But then that would then violate the uniform access principle because
hash/key access has a different syntax from object/method?
Have I missed a vital clue?
A
Re: Unary dot
Andy Wardley [EMAIL PROTECTED] writes:
On Mon, Apr 15, 2002 at 07:24:13PM -0700, Larry Wall wrote:
So the main reason that objects can function as hashes is so that the
user can poke an object into an interface expecting a hash and have it
make sense, to the extent that the object is willing to be viewed like
that.
AKA the uniform access principle.
This was something that I was very keen to exploit in the Template Toolkit
where foo.bar is interpreted as Do(t) The Right Thing to access the
'bar' part of 'foo', be it the 'bar' key in the 'foo' hash or the 'bar'
method of the 'foo' object. The result is, of course, that you can use
a hash of static data one day (great for mocking up web pages for example)
and later upgrade it to an object which fetches/generates data on demand
(e.g. from a database) when you put your pages into production.
Alas, I also designed a flaw into the system by introducing virtual
methods that TT automatically applies onto various data types, equivalent
to various Perl functions, e.g. somehash.keys or somelist.size. As
convenient as this is, the problem lies in the fact that you can't
differentiate somehash.keys between the Perl equivalents of Ckeys %$hash
or C$hash-{keys}.
So my thought for version 3 of TT is to introduce somehash.{keys} as
a syntax to mean only the 'keys' key/method of the 'foo' hash/object
but *NOT* the 'keys' virtual method and to leave somehash.keys resolving
to the virtual method as it currently does.
Am I right in thinking that this would then be (roughly) consistent with
the Perl 6 syntax?
e.g.
TT3 Perl 6 Perl 5 (hash) Perl 5 (obj)
foo.keys $foo.keys keys %$foo $foo-keys()
foo.{keys} $foo.{keys} $foo-{keys} $foo-keys()
Hang on, now I'm a little confused - I thought that hashes were supposed
to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
But then that would then violate the uniform access principle because
hash/key access has a different syntax from object/method?
$foo = %hash; # Take a reference to %hash;
$foo.{keys} # get the value keyed by 'keys' in the hash refered
# to by $foo.
$bar = Object.new # Make an object
$bar.{keys} # Get the value of $bar's '$.keys' instance
# variable.
I think that the '.' is optional in this case too...
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
Piers Cawley writes:
: Andy Wardley [EMAIL PROTECTED] writes:
: Hang on, now I'm a little confused - I thought that hashes were supposed
: to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
: But then that would then violate the uniform access principle because
: hash/key access has a different syntax from object/method?
%foo is just a typed reference varaible. $foo works just about as well.
: $foo = %hash; # Take a reference to %hash;
I'd say Copy a reference, since I think of %hash as a reference already.
: $foo.{keys} # get the value keyed by 'keys' in the hash refered
: # to by $foo.
: $bar = Object.new # Make an object
: $bar.{keys} # Get the value of $bar's '$.keys' instance
: # variable.
Mmm. I think it always calls the virtual method, which might or might
not map directly to $.keys, depending on how fancy the accessors get.
If you want a particular type's method regardless of the actual type of
the object, you have to do as in Perl 5 and say
$bar.This::Type::keys()
: I think that the '.' is optional in this case too...
Yes, as long as there's no whitespace before it. I imagine some style
guides will require the dot for that reason. I can just see some poor
schmuck walking out of a job interview because the company requires
dots on all hash subscripts. :-)
Larry
Re: Unary dot
On Mon, 15 Apr 2002, Damian Conway wrote:
More interestingly, it may also be that, by default, the Coperator:{} (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
I'm a tad bit confused on the grounds of classes. Are we allowed to:
%fred = new Flintstone;
Or are class instances limited only to scalars? The former seems a bit
counterintuitive...
Luke
Re: Unary dot
On 4/15/02 1:16 AM, Damian Conway wrote:
More interestingly, it may also be that, by default, the Coperator:{} (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
$foo.bar_attr = 1;
could also be written:
$foo.{bar_attr} = 1;
and still have the same Uniform Access effect.
This would help Perl 6 support legacy Perl 5 OO code
How? Perl 5 code doesn't use ., and if Perl 5 code has to be changed
anyway, why not change it all the way?
(not to mention legacy Perl 5 OO coders ;-)
I dunno, the $foo.{bar_attr} calls a method thing seems kind of pointless
(and mildly evil) to me. It seems like a throwback to the bad old days of
tied-hashes-as-oo.
-John
Re: Unary dot
$foo.{bar_attr} = 1;
This would help Perl 6 support legacy Perl 5 OO code
How? Perl 5 code doesn't use ., and if Perl 5 code has to be changed
anyway, why not change it all the way?
Because changing:
$foo-{bar_attr}
to:
$foo.{bar_attr}
is a generic, purely syntactic change and easily automated, whereas changing
it to:
$foo.bar_attr
is a semantic change (why does *this* particular instance change to a method
call, rather than a hash look-up?) and consequently *much* harder to get right.
(not to mention legacy Perl 5 OO coders ;-)
I dunno, the $foo.{bar_attr} calls a method thing seems kind of pointless
(and mildly evil) to me. It seems like a throwback to the bad old days of
tied-hashes-as-oo.
Sure. *You* would never do it. Neither would I. But TMTOWTDI.
And if we don't support this, people will be forever having to create Perl 6
adapter classes just so that they can make use of legacy Perl 5 code. :-(
Damian
Re: Unary dot
Luke Palmer wrote:
More interestingly, it may also be that, by default, the Coperator:{} (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
I'm a tad bit confused on the grounds of classes. Are we allowed to:
%fred = new Flintstone;
No. Not as you envisage it. Perl 6 objects aren't hashes.
Or are class instances limited only to scalars? The former seems a bit
counterintuitive...
Yep. Perl 6 usage in this respect will be like Perl 5 usage. The constructor of
a class will return a reference, which will normally be stored in a scalar.
The difference in Perl 6 is that the object is an opaque type: not a hash,
not an array, not a scalar, sub, regex, glob, but a mysterious, encapsulated,
impenetrable something of type OBJECT.
The Coperator:{} method of which I spoke is the perl 6 equivalent of the
CFETCH method of a tied hash (but without having the overhead of tying anything).
Damian
Re: Unary dot
On 4/15/02 5:16 PM, Damian Conway wrote:
if we don't support this, people will be forever having to create Perl 6
adapter classes just so that they can make use of legacy Perl 5 code. :-(
Okay, how about making it a pragma that's not enabled by default? So all
those Perl 5 porters can do their mechanical transformation of -{} to .{}
and then add a no strict hashmethods; (or something) to the top of the
file? Leaving auto-method-call-on-{} in Perl 6 enabled by default seems
like a tacit endorsement of that style (albeit a purely visual distinction
in Perl 6, but why even endorse that?)
(stage 2: bargaining ;)
-John
Re: Unary dot
[EMAIL PROTECTED] writes:
: On 4/15/02 5:16 PM, Damian Conway wrote:
: if we don't support this, people will be forever having to create Perl 6
: adapter classes just so that they can make use of legacy Perl 5 code. :-(
:
: Okay, how about making it a pragma that's not enabled by default? So all
: those Perl 5 porters can do their mechanical transformation of -{} to .{}
: and then add a no strict hashmethods; (or something) to the top of the
: file? Leaving auto-method-call-on-{} in Perl 6 enabled by default seems
: like a tacit endorsement of that style (albeit a purely visual distinction
: in Perl 6, but why even endorse that?)
:
: (stage 2: bargaining ;)
Heh. Well. The main point of doing this isn't really the migration
from Perl 5, but a basic underlying philosophy of linguistics known as
tagmemics. The grammars of natural language are a convenient cultural
fiction, but within a particular context, you can often violate the
official grammatical and lexical rules in order to communicate. A
common manifestation of this in English is the verbing of nouns.
Just because something is officially a noun in English doesn't mean it
can't *function* as a verb. (In computer science this concept tends to
show up more under the term polymorphism, but it's a similar idea.)
More violent examples are easy to come up with. For instance, you can
use an entire sentence as an adjective:
I don't like your I-can-use-anything-as-an-adjective attitude.
The point is, natural languages aren't terribly picky about what you
poke into a particular grammatical slot as long as it makes sense.
So the main reason that objects can function as hashes is so that the
user can poke an object into an interface expecting a hash and have it
make sense, to the extent that the object is willing to be viewed like
that. And the default operator:{} method will let the user access the
existing accessors as if they were keys in a hash. And maybe even use
keys() on the object to get a list of available accessor method names.
If you don't want your objects used this way, it'd be trivial to
override the operator:{} method.
As for avoiding it via a pragma, I'd consider that error prone.
Suppose you call an interface that is defined to return a hash. The
module writer could decide to upgrade the interface to return an object
pretending to be a hash, and your code would break if it had already
decided on its own that only hashes can behave like hashes.
Larry
Re: Unary dot
On 4/15/02 10:24 PM, Larry Wall wrote:
So the main reason that objects can function as hashes is so that the
user can poke an object into an interface expecting a hash and have it
make sense, to the extent that the object is willing to be viewed like
that.
Sure, by why should that be the default?
And the default operator:{} method will let the user access the
existing accessors as if they were keys in a hash. And maybe even use
keys() on the object to get a list of available accessor method names.
I think I liked this idea better when it was called tied hashes, and when it
had to be explicitly enabled by the programmer, rather then explicitly
disabled.
If you don't want your objects used this way, it'd be trivial to
override the operator:{} method.
I'd turn that around and say: if you want your object to behave like a hash,
it'd be trivial to inherit from the HashAccessors class (or whatever). It
just doesn't seem like something that should be in UNIVERSAL (or on by
default, however that's implemented in Perl 6).
IMO, fancy tie-like object-as-another-data-type (tagmemics? ;) features
should need to be explicitly enabled by inheritance and/or operator
overloading (I see your point about the pragma technique).
-John
Re: Unary dot
On Sat, Apr 13, 2002 at 05:07:37PM -0700, Larry Wall wrote: Of course, one of the big reasons we went with $self was the pun: my $self = shift; which we won't have now. Unless we always hide the invocant and force you to say my $self = invocant; or some such mummery. But that seems a bit retro. But now we have endless possibilities for $self.ish $self.less $self.centred $self.obsessed etc. -- But Sidley Park is already a picture, and a most amiable picture too. The slopes are green and gentle. The trees are companionably grouped at intervals that show them to advantage. The rill is a serpentine ribbon unwound from the lake peaceably contained by meadows on which the right amount of sheep are tastefully arranged. Lady Croom - Arcadia
Re: Unary dot
One of the features I like about Eiffel is what Meyer calls the Uniform
Access principle...It sounds as though Perl 6 is heading towards supporting
this. Have we actually got there?
That's the intention, yes.
The details still need to be nutted out, but it seems very likely that if you
write:
class Foo { # version 1
my $.bar_attr is public;
}
then you'll get an automagically created lvalue accessor method that will allow
you to write:
my $foo = Foo.new();
$foo.bar_attr = 1;
and then later define a real CFoo::bar_attr method to encapsulate it:
class Foo { # version 2
my $.bar_attr;
method bar_attr is rw($rvalue) () {
if exists $rvalue {
croak Negative value if $rvalue 0;
$.bar_attr = $rvalue;
}
return $.bar_attr;
}
}
More interestingly, it may also be that, by default, the Coperator:{} (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
$foo.bar_attr = 1;
could also be written:
$foo.{bar_attr} = 1;
and still have the same Uniform Access effect.
This would help Perl 6 support legacy Perl 5 OO code
(not to mention legacy Perl 5 OO coders ;-)
Damian
Re: Unary dot
[EMAIL PROTECTED] writes: : Dave Mitchell wrote: : : The top 20 'my $var' declarations in .pm files in the bleedperl : distribution: : : How *dare* you introduce hard data into this discussion! : Next you'll be wanting to deal in actual facts rather than personal : opinion and sheer guesses!! : : ;-) : : Thanks, Dave. Very illuminating. Of course, one of the big reasons we went with $self was the pun: my $self = shift; which we won't have now. Unless we always hide the invocant and force you to say my $self = invocant; or some such mummery. But that seems a bit retro. Larry
Re: Unary dot
On Thu, Apr 11, 2002 at 08:49:40AM -0700, Larry Wall wrote:
Aaron Sherman writes:
: On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
: $foo.instancevar = 7;
:
: This should not be allowed.
Well, that depends on what you mean by this. :-)
That is, in fact, calling an accessor function, and if it's not allowed,
it's because the attribute is marked private, not because we're against
people thinking of it as a struct.
: External code should not access instance
: variables. We did discuss the idea that accessors would be created
: automatically, and coincidentally, you're using the correct syntax for
: that above, but certainly there should be the ability to override the
: default accessor and to declare an instance variable as accessor-less.
By default attributes are private, which means the corresponding
accessor name is also private. There's no need to override the
automatic accessor merely to make something accessor-less to the
general public.
: In Perl5 C$object{instancevar} = 7 is just frowned on. In Perl6, I
: thought we had agreed that it would flat out be impossible.
Who agreed to that? First of all, it's perfectly possible that (for a
non-hash) that syntax is isomorphic to
$object.instancevar = 7;
since I've already said that any object can be used as if it were a
hash. Plus we'll have lvalue methods in some fashion or other. Not by
default, of course. It's up to the class to decide how much it wants
to break encapsulation.
One of the features I like about Eiffel is what Meyer calls the Uniform
Access principle, which he describes as All services offered by a module
should be available through a uniform notation, which does not betray
whether they are implemented through storage or through computation.
In other words, the users of my module shouldn't have to worry about
whether they are calling a method or accessing an instance variable, and
when I change my implementation from one to the other they shouldn't
have to change their code.
See http://www.elj.com/elj/v1/n1/bm/urp/ for more details.
Languages like C++ don't support this and you end up writing lots of
accessor functions. Do that in Perl 5 and you pay the price of calling
a subroutine.
It sounds as though Perl 6 is heading towards supporting this. Have we
actually got there?
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Unary dot
Dave Mitchell wrote: The top 20 'my $var' declarations in .pm files in the bleedperl distribution: How *dare* you introduce hard data into this discussion! Next you'll be wanting to deal in actual facts rather than personal opinion and sheer guesses!! ;-) Thanks, Dave. Very illuminating. Damian
Re: Unary dot
On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
Ah, but I think the mnemonic value of the '.' more than earns its keep
here. Cour $foo is private is doing a slightly different job
anyway. And instance variables are *not* the same as 'normal'
variables, they hang off a different symbol table (or syte, to use
Damian's oh so clever term from Perl 5+i) and I'm all for things that
are different *looking* different.
Well, I certainly don't like the aesthetic value of them. They are ugly
as Perl 4. But, I have been caught in C++ making all my private variables
_named _like _this, so I suppose it's analogous. But I don't like being
forced to do it that way.
What if you just want a simple struct-like thing? That's when it becomes
really ugly and dislikable. Erm... wait a minute, how would you do that?
$foo = new Foo;
$foo..instancevar = 7;
I doubt that's it.
$foo.instancevar = 7;
This should not be allowed. External code should not access instance
variables. We did discuss the idea that accessors would be created
automatically, and coincidentally, you're using the correct syntax for
that above, but certainly there should be the ability to override the
default accessor and to declare an instance variable as accessor-less.
In Perl5 C$object{instancevar} = 7 is just frowned on. In Perl6, I
thought we had agreed that it would flat out be impossible.
Re: Unary dot
Aaron Sherman writes:
: On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
: Ah, but I think the mnemonic value of the '.' more than earns its keep
: here. Cour $foo is private is doing a slightly different job
: anyway. And instance variables are *not* the same as 'normal'
: variables, they hang off a different symbol table (or syte, to use
: Damian's oh so clever term from Perl 5+i) and I'm all for things that
: are different *looking* different.
:
:
: Well, I certainly don't like the aesthetic value of them. They are ugly
: as Perl 4. But, I have been caught in C++ making all my private variables
: _named _like _this, so I suppose it's analogous. But I don't like being
: forced to do it that way.
:
: What if you just want a simple struct-like thing? That's when it becomes
: really ugly and dislikable. Erm... wait a minute, how would you do that?
:
: $foo = new Foo;
: $foo..instancevar = 7;
: I doubt that's it.
:
: $foo.instancevar = 7;
:
: This should not be allowed.
Well, that depends on what you mean by this. :-)
That is, in fact, calling an accessor function, and if it's not allowed,
it's because the attribute is marked private, not because we're against
people thinking of it as a struct.
: External code should not access instance
: variables. We did discuss the idea that accessors would be created
: automatically, and coincidentally, you're using the correct syntax for
: that above, but certainly there should be the ability to override the
: default accessor and to declare an instance variable as accessor-less.
By default attributes are private, which means the corresponding
accessor name is also private. There's no need to override the
automatic accessor merely to make something accessor-less to the
general public.
: In Perl5 C$object{instancevar} = 7 is just frowned on. In Perl6, I
: thought we had agreed that it would flat out be impossible.
Who agreed to that? First of all, it's perfectly possible that (for a
non-hash) that syntax is isomorphic to
$object.instancevar = 7;
since I've already said that any object can be used as if it were a
hash. Plus we'll have lvalue methods in some fashion or other. Not by
default, of course. It's up to the class to decide how much it wants
to break encapsulation.
Larry
Re: Unary dot
On Thu, 2002-04-11 at 11:49, Larry Wall wrote:
Aaron Sherman writes:
: This should not be allowed.
Well, that depends on what you mean by this. :-)
[...]
: In Perl5 C$object{instancevar} = 7 is just frowned on. In Perl6, I
: thought we had agreed that it would flat out be impossible.
Who agreed to that? First of all, it's perfectly possible that (for a
non-hash) that syntax is isomorphic to
$object.instancevar = 7;
We're in violent agreement ;)
What I was saying was that C$.x ne C$obj.x. One is directly
accessing an instance variable and one is an accessor (which may in fact
be optimized by the compiler in some cases, but the control still lies
in the hands of the class author). Further, I was refering to a previous
thread (no ref handy) where it was stated that instance variables would
be private and accessors would be created automatically (which you
reiterate and clarify in your response here).
I agree that there may be code that looks an awful lot like hash access,
and in practice some of those usages may even BE simple hash access
after compiler optimization. The key difference is that that is all
under the control of the class author (or rather the class author has
the right/ability to give up control). When the author wishes for
something that looks like instance variable access to become a remote
procedure call or have some taint checking performed, this too should be
their choice (and hopefully would not have to involve any Ctieing or
the like, but would instead fall neatly out of the way accessors work).
I think you have agreed with the above, but I was stating it too quicky
in my original post, and it came out like a statement that the syntax of
instance variable access would never be allowed again, when I was only
refering to the semantic.
Re: Unary dot
David == David Whipp [EMAIL PROTECTED] writes: David If every object has a Cclass method (Cref?), then you could David always call class-methods as class.m2(). Wouldn't that be .class.m2(), or did I miss something in the flurry? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Unary dot
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 Cgiven 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 Cis, 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
Re: Unary dot
Allison Randal wrote:
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.
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.
Yes, yes, be explicit. If the current topic is an object, its methods
get invoked by unary dot, be it inside a method or outside a method.
Direction 2 moves into the more exciting but scarier realm of alternate
defaults.
It could, but how about an alternative?
Need there be a unary dot to specify invocation of an alternate method
in the same class as the method being compiled? In other words, the
following rules:
1) A method implicitly defines the default topic to be the object on
which it was invoked.
2) Unary dot uses the default topic as the object on which to invoke
methods. If the default topic is not an object, an exception results.
3) The function call name space within a method is first other methods
of the same class, then other functions. (This is similar to C++, I
believe)
Hence, given a class containing two methods m1 and m2...
method m1
{
m2; # calls method m2 in the same class
m2; # this should do the same, if the is still permitted
.m2; # syntax error
given ( $other_object )
{
when m2 { ... } # invokes method m2 in the same class
when .m2 { ... } # invokes $other_object.m2
when $_.m2 { ... } # invokes $other_object.m2
when $self.m2 { ... } # syntax error, unless some use invocant
self
# directive is included somewhere in the
scope
# If it is, then invokes method m2 in same
class
}
}
--
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.
Re: Unary dot
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
.m2; # syntax error
Doesn't that violate your stated rule thatthe default topic within a
method be the invocant? Shouldn't .m2 be equivalent to $_.m2?
--
Mark J. REED[EMAIL PROTECTED]
RE: Unary dot
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
I would expect the the m2() call would use the invocant of m1.
If m1 is a called as a class method, then m2 would, also.
If every object has a Cclass method (Cref?), then you could
always call class-methods as class.m2().
Dave.
Re: Unary dot
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
Should both be allowed to exist? Do both exist? Why do both exist?
(with the same name). If only one exists, then that would be the one
that gets called.
.m2; # syntax error
Doesn't that violate your stated rule thatthe default topic within a
method be the invocant? Shouldn't .m2 be equivalent to $_.m2?
Oops. Yep, got me there. I should have wrapped a given $non_object
around that one. Thanks.
--
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.
Re: Unary dot
On Wed, Apr 10, 2002 at 10:50:52AM -0700, Glenn Linderman wrote: Yes, but does it call it as an instance method on the current invocant or as a class method with no invocant? If the former, how would you do the latter? Should both be allowed to exist? Do both exist? Why do both exist? (with the same name). If only one exists, then that would be the one that gets called. Making the decision based on existence implies a requirement that Perl6 methods be explicitly declared as either class or instance. Not that there's anything wrong with that; I'm just not aware of that decision having been made. I guess we won't find out for sure until either Apoc6 or Apoc12? -- Mark J. REED[EMAIL PROTECTED]
Re: Unary dot
David Whipp wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
I would expect the the m2() call would use the invocant of m1.
If m1 is a called as a class method, then m2 would, also.
If every object has a Cclass method (Cref?), then you could
always call class-methods as class.m2().
Dave.
Thanks, Dave, that's an excellant idea.
--
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.
Re: Unary dot
At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
Should both be allowed to exist? Do both exist? Why do both exist?
(with the same name). If only one exists, then that would be the one
that gets called.
I'd hope it would assume instance method until told otherwise,
since static methods (class methods) are seldom used in OOP.
Also there are issues when just assuming if m1() is a class method,
I call m2() as a class method because m2() may access instance
data that wouldn't exist if it were called staticly.
-Melvin
Re: Unary dot
Melvin Smith [EMAIL PROTECTED] writes:
At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
Should both be allowed to exist? Do both exist? Why do both exist?
(with the same name). If only one exists, then that would be the one
that gets called.
I'd hope it would assume instance method until told otherwise,
since static methods (class methods) are seldom used in OOP.
Um... don't you use factory methods? I know I do.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
Graham.
Re: Unary dot
Graham Barr wrote:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
The same way. If there is a name conflict between subroutine and
methods, then you qualify the subroutine name...
::m2; # calls global subroutine main::m2
main::m2; # calls global subroutine main::m2
--
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.
Re: Unary dot
Graham Barr [EMAIL PROTECTED] writes:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
And anyone who says You don't will receive a good hard talking to
from me. Being able to declare private subroutines within classes is
really useful, witness:
class SchemeNumber is SchemeExpr {
my sub apply($self: $target, $rhs, block) {
if $is_rhs { $self.new(+ block( $target, $self.value )) }
else { $self.new(+ block( $self.value, $target )) }
}
method operator:+ { apply(*@_, {$^a + $^b}) }
method operator:* { apply(*@_, {$^a * $^b}) }
method operator:- { apply(*@_, {$^a * $^b}) }
method operator:/ { apply(*@_, {$^a * $^b}) }
method is_number { 1 }
}
Yes, I know there's several different ways I could do it, but this
approach feels right.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
Glenn Linderman [EMAIL PROTECTED] writes:
Graham Barr wrote:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
The same way. If there is a name conflict between subroutine and
methods, then you qualify the subroutine name...
::m2; # calls global subroutine main::m2
main::m2; # calls global subroutine main::m2
This is looking more and more horrible Glenn.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote: ::m2; # calls global subroutine main::m2 main::m2; # calls global subroutine main::m2 This is looking more and more horrible Glenn. I think we need to back off of unmarked subroutines becoming a method call. That one extra '.' in front isn't too much, is it? I like the following, assumed to be within method m1: ..m2();# call m2 the same way m1 was called, instance or class $_.m2(); # same thing? Does the class become the topic in a static method? ..class.m2: # call static m2 within m1's class, regardless of how m1 was called m2() # call subroutine m2 with no arguments, implied or otherwise -- Mark J. REED[EMAIL PROTECTED]
Re: Unary dot
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
Allison Randal wrote:
Direction 2 moves into the more exciting but scarier realm of alternate
defaults.
It could, but how about an alternative?
Ah-ha, yet a third Direction!
Need there be a unary dot to specify invocation of an alternate method
in the same class as the method being compiled? In other words, the
following rules:
1) A method implicitly defines the default topic to be the object on
which it was invoked.
As has been mentioned, this is already true.
2) Unary dot uses the default topic as the object on which to invoke
methods. If the default topic is not an object, an exception results.
Well, since all the variable types are now objects, which have methods,
this wouldn't happen. But you would get some sort of exception if there
was no method of that name for the current object.
3) The function call name space within a method is first other methods
of the same class, then other functions. (This is similar to C++, I
believe)
Hence, given a class containing two methods m1 and m2...
method m1
{
m2; # calls method m2 in the same class
m2; # this should do the same, if the is still permitted
.m2; # syntax error
given ( $other_object )
{
when m2 { ... } # invokes method m2 in the same class
when .m2 { ... } # invokes $other_object.m2
when $_.m2 { ... } # invokes $other_object.m2
when $self.m2 { ... } # syntax error, unless some use invocant
self
# directive is included somewhere in the
scope
# If it is, then invokes method m2 in same
class
}
}
I kind of like the idea of having both topic and invocant available
at all times. But, I am concerned at having such a huge semantic
difference (which object you're using) relying on the subtle visual
distinction between m2() and .m2(). I can see a large opportunity for
coder error and newbie misunderstanding. You also lose the visual cue
that says this is a method call, not a subroutine or a built-in
function. In the end I think that might be more confusing than it's
worth.
Allison
Re: Unary dot
On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: ..class.m2: # call static m2 within m1's class, regardless of how m1 was called Typo. That should be just .class.m2, only one leading '.'. -- Mark J. REED[EMAIL PROTECTED]
RE: Unary dot
Mark J. Reed wrote On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: ..class.m2: # call static m2 within m1's class, regardless of how m1 was called Typo. That should be just .class.m2, only one leading '.'. Wouldn't that be the current topic's class? Dave.
Re: Unary dot
On Wed, Apr 10, 2002 at 12:12:56PM -0700, David Whipp wrote: Mark J. Reed wrote On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: ..class.m2: # call static m2 within m1's class, regardless of how m1 was called Typo. That should be just .class.m2, only one leading '.'. Wouldn't that be the current topic's class? .. . . and not necessarily the class in which m1 was declared. Good point. I was assuming a simpler, inheritance-free case. -- Mark J. REED[EMAIL PROTECTED]
Re: Unary dot
On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote: ::m2; # calls global subroutine main::m2 main::m2; # calls global subroutine main::m2 This is looking more and more horrible Glenn. I think we need to back off of unmarked subroutines becoming a method call. Yeah. I like the following, assumed to be within method m1: ..m2(); # call m2 the same way m1 was called, instance or class This has already been semi-rejected. I agree with the reasoning. Not that it wouldn't be nice to have a way to code the concept, just that the .. symbology isn't right for the job. $_.m2(); # same thing? Does the class become the topic in a static method? If ..m2() were the same as $self.m2(), $_.m2() would only be the same until you entered the scope of another topicalizer. m2() # call subroutine m2 with no arguments, implied or otherwise Agreed. Allison
Re: Unary dot
On Wed, Apr 10, 2002 at 02:42:58PM -0500, Allison Randal wrote: I like the following, assumed to be within method m1: ..m2();# call m2 the same way m1 was called, instance or class This has already been semi-rejected. I agree with the reasoning. Not that it wouldn't be nice to have a way to code the concept, just that the .. symbology isn't right for the job. MUA/MTA quoting seems to be getting in the way here - someone's prepending a '.' to avoid sending the SMTP end-of-message sentinel and it's not getting stripped off properly. That was supposed to be a single '.' in front of the m2(). In other words, unary . is the same as binary . with $_ as the LHS, so .m2() would be the same as $_.m2(). Which would have the semantics in my comment above, assuming that the class becomes the topic in static methods. -- Mark J. REED[EMAIL PROTECTED]
Re: Unary dot
Mark J. Reed [EMAIL PROTECTED] writes: On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote: ::m2; # calls global subroutine main::m2 main::m2; # calls global subroutine main::m2 This is looking more and more horrible Glenn. I think we need to back off of unmarked subroutines becoming a method call. That one extra '.' in front isn't too much, is it? I like the following, assumed to be within method m1: ..m2(); # call m2 the same way m1 was called, instance or class Can't say I'm keen on that at all. We already have a '..' operator (admittedly it's binary), and this new, unary .. doesn't really do anything remotely similar (cf unary dot, unary _ and unary +, which have behaviours which are obviously related to the binary forms.). And haven't we done this discussion already? -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
RE: Unary dot
Piers Cawley This may be a case of keep up at the back, but if that is a method call, how do I call a subroutine from within a method ? [...] Yes, I know there's several different ways I could do it, but this approach feels right. I think this comes does to huffmann encoding: which things are common, and which are less common. This probably depends on what you are doing (what paradigm you are following), so its really a question about the nature of perl. The things I've heard people wanting to do are: call method on current topic call method on current invocant call class method on invocant's class call private subroutine defined in current class call global subroutine The following syntaxes have been seen: foo() .foo() ..foo() ## rejected because .. is different binary op class.foo() FooClass.foo() ::foo() Package::foo() $foo() $_.foo() I see 2 partionings: * by scope: topic, self, named package, global * by invocant: instance, class, none My suggested resolutions: By Scope: global/ named package use the existing Foo::bar syntax; Topic uses unary . syntax; self uses nothing By invocant: infer from current invocant/topic; use foo() for no invocant Thus, the perl5 transalations would be: foo() = $self-foo() .foo() = $_-foo() foo() = foo() ::foo() = ::foo() Bar::bar() = Bar::bar() class.foo() = ref($self)-foo() .class.foo() = ref($_)-foo() foo(self) = foo($self-self) = $self-self-foo() This assumes that Cclass and Cself are defined in UNIVERSAL Dave.
Re: Unary dot
David Whipp [EMAIL PROTECTED] writes: Piers Cawley This may be a case of keep up at the back, but if that is a method call, how do I call a subroutine from within a method ? [...] Yes, I know there's several different ways I could do it, but this approach feels right. I think this comes does to huffmann encoding: which things are common, and which are less common. This probably depends on what you are doing (what paradigm you are following), so its really a question about the nature of perl. The things I've heard people wanting to do are: call method on current topic call method on current invocant call class method on invocant's class call private subroutine defined in current class call global subroutine The following syntaxes have been seen: foo() .foo() ..foo() ## rejected because .. is different binary op class.foo() FooClass.foo() ::foo() Package::foo() $foo() $_.foo() I see 2 partionings: * by scope: topic, self, named package, global * by invocant: instance, class, none My suggested resolutions: By Scope: global/ named package use the existing Foo::bar syntax; Topic uses unary . syntax; self uses nothing By invocant: infer from current invocant/topic; use foo() for no invocant Thus, the perl5 transalations would be: foo() = $self-foo() .foo() = $_-foo() foo() = foo() ::foo() = ::foo() Bar::bar() = Bar::bar() class.foo() = ref($self)-foo() .class.foo() = ref($_)-foo() foo(self) = foo($self-self) = $self-self-foo() This assumes that Cclass and Cself are defined in UNIVERSAL For reasons that I can't quite put my finger on at the moment, I really, really don't like that approach. One of the really nice things about perl 4 was that we didn't have to use any more. Making it essential seems like a horribly retrograde step. I suppose you could require the only when calling subroutines from within a method/class definitions, but I still don't like it. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Unary dot
The following syntaxes have been seen: foo() .foo() ..foo() ## rejected because .. is different binary op class.foo() FooClass.foo() ::foo() Package::foo() $foo() $_.foo() With a nod to Piers, and with apologes if this is silly in the context of Perl 6 syntax, what about: $.foo -- ralph
Re: Unary dot
On Wed, Apr 10, 2002 at 03:49:44PM -0400, Mark J. Reed wrote: On Wed, Apr 10, 2002 at 02:42:58PM -0500, Allison Randal wrote: I like the following, assumed to be within method m1: ..m2(); # call m2 the same way m1 was called, instance or class This has already been semi-rejected. I agree with the reasoning. Not that it wouldn't be nice to have a way to code the concept, just that the .. symbology isn't right for the job. MUA/MTA quoting seems to be getting in the way here - someone's prepending a '.' to avoid sending the SMTP end-of-message sentinel and it's not getting stripped off properly. That was supposed to be a single '.' in front of the m2(). Then, Agreed. In other words, unary . is the same as binary . with $_ as the LHS, so .m2() would be the same as $_.m2(). Which would have the semantics in my comment above, Yes, until you used a Cgiven or a Cfor, etc. Then .m2() would be the same as $_.m2() (at least it would be if we don't make any of the changes we're talking about), but wouldn't be called the same way m1 was called, it would be called on the current topic. assuming that the class becomes the topic in static methods. Larry Wall wrote in A4: Any method definition is a topicalizer within the body of the method, and will assume a given of its $self object (or whatever you have named it). I would hope that static methods wouldn't be *too* different from instance methods. Allison
Re: Unary dot
On Wed, Apr 10, 2002 at 09:23:23PM +0100, Piers Cawley wrote: David Whipp [EMAIL PROTECTED] writes: Thus, the perl5 transalations would be: foo() = $self-foo() .foo() = $_-foo() foo() = foo() ... For reasons that I can't quite put my finger on at the moment, I really, really don't like that approach. One of the really nice things about perl 4 was that we didn't have to use any more. Making it essential seems like a horribly retrograde step. I suppose you could require the only when calling subroutines from within a method/class definitions, but I still don't like it. I agree. It makes an exception where none is needed (foo() required instead of foo()) just to re-use the syntax for a less common construction that could just as easily be represented any number of other ways. Allison
Re: Unary dot
David Whipp [EMAIL PROTECTED] writes: Thus, the perl5 transalations would be: foo() = $self-foo() .foo() = $_-foo() foo() = foo() ... Alternative: $self.foo() = $self-foo() # and can be .foo() when $self is $_ .foo() = $_-foo() # but might be altered by a pragma foo() = foo() Allison
Re: Unary dot
$.foo It's already defined as an instance variable. I don't think I like that. Instance variables are far more common that class variables, so why not just $foo, and you could use a compile-time property for class variables. Like Cis private as discussed. That or Cis static. I think the latter makes more sense. Or is there some reason this wouldn't work? Luke
Re: Unary dot
Allison wrote:
David Whipp [EMAIL PROTECTED] writes:
Thus, the perl5 transalations would be:
foo() = $self-foo()
.foo() = $_-foo()
foo() = foo()
...
Alternative:
$self.foo() = $self-foo() # and can be .foo() when $self is $_
.foo() = $_-foo() # but might be altered by a pragma
foo() = foo()
And welcome back to where we started! ;-)
However, having circumnavigated the alternatives, we now have a better
perspective on the trade-offs and hidden costs.
The original idea of topicalizing the invocant in methods was that it makes
very simple methods even simpler:
method name { .assigned_name // .std_name // ??? }
For anything more complex than very simple (i.e. anything with internal
topicalizers), one names the invocant explicitly:
method rank ($self:) {
given ($.status) {
when covert { return Special operative }
when detached { return Field operative }
default { return $self.actual_rank }
}
}
or, if the class has many such methods, implicitly:
use invocant 'invocant';
method rank () {
given ($.status) {
when covert { return Special operative }
when detached { return Field operative }
default { return invocant.actual_rank }
}
}
The problem that this discussion has highlighted is that using a
bare .foo in a method means the reader/maintainer has to track what
the current topic is in order to know who the current invocant is.
That would seem to be a (potentially expensive) hidden cost of this idiom.
Reflecting on this, it seems that it would be useful if methods
implicitly did their default topicalization-of-invocant like so:
- $self
rather than just:
- $_
That is, that as well as aliasing the invocant to $_, they also alias it
to some standard variable name.
Then one would be guaranteed an invariant name (across all OO Perl!)
for the invocant, even under internal topicalizations.
Of course, the problem is then: what should the name of this topicalizer
variable be? The main options are:
$self
$me
$I
$this
$invocant
$object
$obj
And frankly, that's a very minor issue. Someone (i.e. Larry) should just
pick one and then we can all move on.
Damian
Re: Unary dot
On Thu, Apr 11, 2002 at 08:04:56AM +1000, Damian Conway wrote: Allison wrote: $self.foo() = $self-foo() # and can be .foo() when $self is $_ .foo() = $_-foo() # but might be altered by a pragma foo() = foo() And welcome back to where we started! ;-) Exactly! :) The problem that this discussion has highlighted is that using a bare .foo in a method means the reader/maintainer has to track what the current topic is in order to know who the current invocant is. That would seem to be a (potentially expensive) hidden cost of this idiom. But possibly less expensive than providing a means to default to something other than topic. That is, that as well as aliasing the invocant to $_, they also alias it to some standard variable name. Then one would be guaranteed an invariant name (across all OO Perl!) for the invocant, even under internal topicalizations. I'm in favor of the standardized variable name. It is a restriction, but not an onerous one. I've never used anything but $self, and I'm sure it would be easy to adapt to whatever else was chosen. Are there any statistics availble on current usage of $self vs. $this vs. whatever? It might be easiest to go with what the majority find most comfortable. Allison
Re: Unary dot
At 07:40 PM 4/10/2002 +0100, Piers Cawley wrote:
Melvin Smith [EMAIL PROTECTED] writes:
At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
Should both be allowed to exist? Do both exist? Why do both exist?
(with the same name). If only one exists, then that would be the one
that gets called.
I'd hope it would assume instance method until told otherwise,
since static methods (class methods) are seldom used in OOP.
Um... don't you use factory methods? I know I do.
Sure I do, but it doesn't comprise more than 5% of the methods I call
on objects. And in C++ or Java, when I need a class method, I
specify it with the keyword 'static'. Along with it comes the restrictions
of not accessing instance data, etc. etc.
I will admit my applied usage of OOP is biased by the C++/Java
lense. :)
While I may be misunderstanding Perl6 syntax, I'm not misunderstanding
OOP, these are basic concepts to C++ and Java and how many
other languages; granted, I'll try to play catchup with reading the Apocs and
Exegeses over, but it appears from the discussion thread that people
are discussing class/instance method mixing as if this were a new
concept to OOP. My feeling is you ask yourself: What makes sense and what
does the compiler and runtime engine have to do based on the given
rules that we choose.
Its clear if invocant of foo() is the class, and not the instance, calling
an instance method from class scope without creating an object to work
with should either be disallowed, or analyzed to check whether it actually uses
instance data. I'd choose former which is what C++ and Java does.
-Melvin
Re: Unary dot
At 07:54 PM 4/10/2002 +0100, Piers Cawley wrote:
Graham Barr [EMAIL PROTECTED] writes:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
And anyone who says You don't will receive a good hard talking to
from me. Being able to declare private subroutines within classes is
really useful, witness:
class SchemeNumber is SchemeExpr {
my sub apply($self: $target, $rhs, block) {
if $is_rhs { $self.new(+ block( $target, $self.value )) }
else { $self.new(+ block( $self.value, $target )) }
}
method operator:+ { apply(*@_, {$^a + $^b}) }
method operator:* { apply(*@_, {$^a * $^b}) }
method operator:- { apply(*@_, {$^a * $^b}) }
method operator:/ { apply(*@_, {$^a * $^b}) }
method is_number { 1 }
}
Yes, I know there's several different ways I could do it, but this
approach feels right.
I agree, however you passed in the invocant so there is no
ambiguity in your case.
Calling a class method off of an object, I've found use for.
Calling an instance method from a class invocant scope doesn't
make sense to me which is what I _think_ Graham's example
was implying.
I suppose this would be akin to:
if(typeof(self) is 'class') {
...
}
else { # instance
...
}
I think that would be just plain bad design, but I'd be happy if someone
showed me a use for it. :)
-Melvin
Re: Unary dot
At 08:04 AM 4/11/2002 +1000, Damian Conway wrote: And welcome back to where we started! ;-) Wow there is a lot of blood on the ground here. Must have been messy... :) Of course, the problem is then: what should the name of this topicalizer variable be? The main options are: $self $me $I $this $invocant $object $obj And frankly, that's a very minor issue. Someone (i.e. Larry) should just pick one and then we can all move on. I'm waiting for Larry to say, We have decided to use $me, $myself and $i. -Melvin
RE: Unary dot
Melvin Smith wrote
I think that would be just plain bad design, but I'd be happy
if someone showed me a use for it. :)
well, I've been known to do
sub UNIVERSAL::debug
{
my $self = shift;
my $msg = _;
eval {$self=$self-name} if ref($self);
my $timestamp = ...;
my $caller = ...;
print DEBUG [$timestamp] '$self' $caller: $msg\n;
}
sub UNIVERSAL::debugf { shift-debug(sprintf _) }
which can then be called as:
$class-debug(hello);
or
$self-debugf(world, %d, 42);
or even
hello-debug(world);
You are right. This is just plain bad design. But it can be useful.
Dave.
Re: Unary dot
On Thu, Apr 11, 2002 at 08:04:56AM +1000, Damian Conway wrote:
Reflecting on this, it seems that it would be useful if methods
implicitly did their default topicalization-of-invocant like so:
- $self
rather than just:
- $_
That is, that as well as aliasing the invocant to $_, they also alias it
to some standard variable name.
Then one would be guaranteed an invariant name (across all OO Perl!)
for the invocant, even under internal topicalizations.
H... this being the case, is there any reason we should ever need to
name the invocant explicitly? If Perl has already provided a named alias
implicitly, why specify redundant information when other parameters
follow? Leave the parameter lists for parameters that change from method
to method, not for the one that will always be there.
You get short parameter lists, and a truly invariant name for the
invocant.
method foo ($bar, $baz) {
$self.boo; # $self always exists in a method
}
There's no conflict with Perl 5 since Cmethod is a new keyword.
Also, the invocant pragma becomes unnecessary if you can always access
the current object via $self (or $this, or $me, or whatever, as long as
it's not $invocant ;).
My, my, my, I *am* playing the devil's advocate today. :)
Allison
Re: Unary dot
Allison Randal wrote:
H... this being the case, is there any reason we should ever need to
name the invocant explicitly?
Yes. To make it read-writable.
Perl makes that much easier than most other languages, because you can pass
the invocant by (writable) reference, so you don't need to pass a separate
$parent pointer:
method Tree::delete(Tree $self is rw:) {
if $.left_child {
$.left_child.insert($.right_child) if $.right_child;
$self = $.left_child
}
elsif $.right_child {
$self = $.right_child
}
$.right_child = $.left_child = undef;
}
Damian
Re: Unary dot
On Thu, Apr 11, 2002 at 12:01:58PM +1000, Damian Conway wrote: Allison Randal wrote: H... this being the case, is there any reason we should ever need to name the invocant explicitly? Yes. To make it read-writable. Curses! Foiled again! :) Perl makes that much easier than most other languages, because you can pass the invocant by (writable) reference, so you don't need to pass a separate $parent pointer: Devil's advocate role aside, that is a very cool feature. Another thing you would lose is the ability to rename the parameter if you wanted (you could use assignment or binding, but it would be infinitely ugly). Allison
Re: Unary dot
At 04:01 PM 4/10/2002 -0600, Luke Palmer wrote: $.foo It's already defined as an instance variable. I don't think I like that. Instance variables are far more common that class variables, so why not just $foo, and you could use a compile-time property for class variables. Like Cis private as discussed. That or Cis static. I think the latter makes more sense. Or is there some reason this wouldn't work? I totally agree here. The common case is going to make code look ugly with $.foo everywhere. Please don't let this come into being. :( I think it is arguable that a closure is a class for a subroutine object, and in subs we will still use my $foo for lexicals. However we must remember in class scope to use $.foo for the default, instance variable, and a normal $foo for the less typical static or class variables. Yucky. Reserve the ugly syntax for the less common case. Plase. -Melvin
Re: Unary dot
Damian Conway [EMAIL PROTECTED] writes: [...] Reflecting on this, it seems that it would be useful if methods implicitly did their default topicalization-of-invocant like so: - $self rather than just: - $_ That is, that as well as aliasing the invocant to $_, they also alias it to some standard variable name. Then one would be guaranteed an invariant name (across all OO Perl!) for the invocant, even under internal topicalizations. Of course, the problem is then: what should the name of this topicalizer variable be? The main options are: $self $me $I $this $invocant $object $obj And frankly, that's a very minor issue. Someone (i.e. Larry) should just pick one and then we can all move on. Nailing my colours to the mast here, I choose '$self'. I will confess to suggesting the Cuse invocant '$whatever' syntax not because I thought it was a desperately good idea, but because I didn't want to get into arguing about what colour to paint the bikeshed before we'd actually decided whether or not to build the bikeshed in the first place. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Unary dot
Luke Palmer [EMAIL PROTECTED] writes: $.foo It's already defined as an instance variable. I don't think I like that. Instance variables are far more common that class variables, so why not just $foo, and you could use a compile-time property for class variables. Like Cis private as discussed. That or Cis static. I think the latter makes more sense. Ah, but I think the mnemonic value of the '.' more than earns its keep here. Cour $foo is private is doing a slightly different job anyway. And instance variables are *not* the same as 'normal' variables, they hang off a different symbol table (or syte, to use Damian's oh so clever term from Perl 5+i) and I'm all for things that are different *looking* different. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Unary dot
Ah, but I think the mnemonic value of the '.' more than earns its keep here. Cour $foo is private is doing a slightly different job anyway. And instance variables are *not* the same as 'normal' variables, they hang off a different symbol table (or syte, to use Damian's oh so clever term from Perl 5+i) and I'm all for things that are different *looking* different. Well, I certainly don't like the aesthetic value of them. They are ugly as Perl 4. But, I have been caught in C++ making all my private variables _named _like _this, so I suppose it's analogous. But I don't like being forced to do it that way. What if you just want a simple struct-like thing? That's when it becomes really ugly and dislikable. Erm... wait a minute, how would you do that? $foo = new Foo; $foo..instancevar = 7; I doubt that's it. $foo.instancevar = 7; And that's unclear, if we refer to it as $.instancevar inside the function. Or, actually, I do think it's clear. Wow, I was arguing my point and I came to like the syntax. Hmm Ok, take your once-ugly syntax and run with it! I understand it now. Luke
Re: Unary dot
But suppose you want all .foo to refer to self and not
to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what about 'me' or 'i' instead of 'self'?
And use me; instead of use invocant;?
--
me
PS. Please don't flame me, my assistant wrote this.
Re: Unary dot
Me [EMAIL PROTECTED] writes:
But suppose you want all .foo to refer to self and not
to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what about 'me' or 'i' instead of 'self'?
Keep up at the back.
use invocant 'me';
PS. Please don't flame me, my assistant wrote this.
Whereth hith lithp?
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
Me writes:
: But suppose you want all .foo to refer to self and not
: to the current topic.
:
: What about
:
: given (self) { }
That wouldn't have the same effect as what we're talking about--it'd be
overruled by any Cgiven within. We're talking about how to make .foo
mean self.foo regardless of the current topic.
: Also, what about
:
: use invocant;
:
: resulting in all method bodies in scope getting an implied
: surrounding given (self) { }.
Er, methods already assume that.
: And what about 'me' or 'i' instead of 'self'?
I think me is too close to my.
: And use me; instead of use invocant;?
And here me is referring to something that doesn't even necessarily
exist at the time of the declaration. Who is me at this point?
In any event, I'm inclined to think that this whole selfish notion of
the object is a bit of a misnomer. We are a programmer. We are not an
object. We use my on lexical declarations because it's my piece of
code. Some of that code just happens to deal with objects, but objects
are them more than they're us. C++ probably has the more accurate
idea here with this, but maybe we've finally found a good place for
the occasionally proposed it:
it.foo(1);
or even better:
close it;
On the other hand, it doesn't interpolate too well. And $_ is still
pronounced it...
But think of the commercial possibilities if your program starts out:
just use it;
Though I do wonder what
use it or lose it;
would mean...
Larry
Re: Unary dot
Larry Wall [EMAIL PROTECTED] writes:
Me writes:
: But suppose you want all .foo to refer to self and not
: to the current topic.
:
: What about
:
: given (self) { }
That wouldn't have the same effect as what we're talking about--it'd be
overruled by any Cgiven within. 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, eg:
use invocant 'it';
method foo($bar) {
given .wibble($bar) {
when .method { it.do_it(.attrib) }
}
}
(I'm assuming here that, in a method, $bar is *not* the same as @_[0],
which one would declare using Cmethod foo($bar:) {...}). In the
above chunk of code it'd be really nice if .method and .attrib were
called on the results of .wibble($bar) (which was called on the
current object), whilst 'it' unambiguously refers to the current
object.
The Cuse invocant 'foo' syntax is just a suggestion (and a way of
dodging arguments about whether to call the object
self/this/that/it/whatever because the programmer can cleave to his
own taste.
: And use me; instead of use invocant;?
And here me is referring to something that doesn't even necessarily
exist at the time of the declaration. Who is me at this point?
Can I propose an 'abuse' builtin? Then one could say: Cuse me; abuse
me;, which has to be good for poetry if nothing else.
In any event, I'm inclined to think that this whole selfish notion
of the object is a bit of a misnomer. We are a programmer. We are
not an object. We use my on lexical declarations because it's my
piece of code. Some of that code just happens to deal with objects,
but objects are them more than they're us. C++ probably has the
more accurate idea here with this, but maybe we've finally found a
good place for the occasionally proposed it:
it.foo(1);
or even better:
close it;
On the other hand, it doesn't interpolate too well. And $_ is
still pronounced it...
Personally, I like the 'self' notation; it encourages the programmer
to think the 'right way around'. 'it' encourages one to think of
objects doing things to objects, 'self' encourages to think of objects
taking responsibility for their own data and asking other objects to
do things for it. Hrm... I think I might need to think about that some
more.
But think of the commercial possibilities if your program starts out:
just use it;
Though I do wonder what
use it or lose it;
would mean...
You are a *bad* man Mister Wall.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
Damian Conway writes:
:use invocant 'self';
Hmm. My first inclination is to say it should be something like:
macro self { '%MY.frame.arg[0]' }
But suppose you want all .foo to refer to self and not to the current
topic. It would be problematic to have a macro whose name is .
So you might say something like this:
use invocant ;
Still a bit odd syntactically, however. One is vaguely tempted to make
..foo(1)
mean self.foo(1). But then we'd see methods chock full of *that* even
when it wasn't necessary. Much rather see self.foo(1).
: *Much* better name. You see, that's why you're the mad genius and I'm
: just the lowly lab assistant. Marthter.
:
: And, given that I'm jutht Larry'th lowly lab aththithtant, that would
: theem to make you a meta-Igor!
:
: %-)
As Annie Oakley almost said, Anything you can do, I can do meta.
Fortunately, Igority is transitive...
Larry
Re: Unary dot
Larry wrote:
:use invocant 'self';
Hmm. My first inclination is to say it should be something like:
macro self { '%MY.frame.arg[0]' }
But suppose you want all .foo to refer to self and not to the current
topic. It would be problematic to have a macro whose name is .
So you might say something like this:
use invocant ;
Still a bit odd syntactically, however.
Perhaps a bare:
use invocant;
overrides unary dot within the lexical scope, causing it to default to using
each method's _[0], rather than $_.
One is vaguely tempted to make
..foo(1)
mean self.foo(1). But then we'd see methods chock full of *that* even
when it wasn't necessary. Much rather see self.foo(1).
Yep. Besides, since we're working towards having the unary version of operators
vaguely related to the binary version in Perl 6 (e.g. unary C_, unary C+,
unary C.), it would seem counterproductive to have unary C.. utterly
unrelated to binary C...
Fortunately, Igority is transitive...
I thought that was maxim was: Igorance is blithth.
Damian
Re: Unary dot
Damian Conway writes: : Fortunately, Igority is transitive... : : I thought that was maxim was: Igorance is blithth. That's not a maxim, that's a minim. Larry
Re: Unary dot
: I thought that was maxim was: Igorance is blithth. That's not a maxim, that's a minim. No need to get all crotchet-y. Damian
Re: Unary dot
Piers == Piers Cawley [EMAIL PROTECTED] writes:
Piers So, is there any chance that we'll be able to do:
Piers class ical {
Piers use object_name '$self';
Piers method ical {
Piers given $self.ology {
Piers ... { $self.ish }
Piers }
Piers }
Piers }
You could use the Smalltalk way by defining method myself in UNIVERSAL,
which simply returns self. So .myself would always be yourself,
which you could store if needed.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Unary dot
Piers asked:
So, is there any chance that we'll be able to do:
class ical {
use object_name '$self';
method ical {
given $self.ology {
... { $self.ish }
}
}
}
Of course, if you're not using explicit parameters, you can always write:
method ical {
given _[0].ology {
... { _[0].ish }
}
}
It would be nice to have a cleaner way to do that, though.
So I'd like to see something like your pragma. However, I'd
probably make it more like:
use invocant 'self';
method ical {
given self.ology {
... { self.ish }
}
}
and then probably use:
use invocant 'me';
to save those two extra characters!
;-)
Damian
Re: Unary dot
Damian Conway [EMAIL PROTECTED] writes:
Piers asked:
So, is there any chance that we'll be able to do:
class ical {
use object_name '$self';
method ical {
given $self.ology {
... { $self.ish }
}
}
}
Of course, if you're not using explicit parameters, you can always write:
method ical {
given @_[0].ology {
... { @_[0].ish }
}
}
It would be nice to have a cleaner way to do that, though.
So I'd like to see something like your pragma. However, I'd
probably make it more like:
use invocant 'self';
*Much* better name. You see, that's why you're the mad genius and I'm
just the lowly lab assistant. Marthter.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
use invocant 'self'; *Much* better name. You see, that's why you're the mad genius and I'm just the lowly lab assistant. Marthter. And, given that I'm jutht Larry'th lowly lab aththithtant, that would theem to make you a meta-Igor! %-) Damian
