Re: method hiding (or not) in derived classes
HaloO, John M. Dlugosz wrote: Perl 6 has a concept of a candidate list. The candidate list are those that could handle the call, typically inherited methods and multi variations. Candidate set would be a better term. It is a subset of all long names of a multi in a lexical scope. It seems that multi variations, at least with respect to the semicolon parameters, compare the actual type and drop out of the list if any don't match. I'm not sure what you are asking. But if a candidate is applicable it competes with the other candidates for specificity. That is what the semicolons are for. And even if a candidate is voted out it still can vote out others. What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? There is hopefully a complete specification what constitutes applicability. There can hardly be differing simpler versions. In other words there is only one subtype relation that is used whenever a binding takes place. If that is the case, then a derived method might not hide a base class method if the parameter list is seriously incompatible. That is a natural and welcome consequence of type based dispatch. Classes are for implementation sharing, not for transitive typing. More interestingly, left-to-right ordering of multiply-inherited base classes will be checked for applicability rather than arbitrarily taking the leftmost. Indeed, I would hope that order of inheritance doesn't matter. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Re: method hiding (or not) in derived classes
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: Candidate set would be a better term. It is a subset of all long names of a multi in a lexical scope. List, not set, because it is ordered. nextsame/nextwith/etc. are described as invoking the next candidate on the list. Therefore, there is a list. What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? There is hopefully a complete specification what constitutes applicability. There can hardly be differing simpler versions. In other words there is only one subtype relation that is used whenever a binding takes place. I have no idea what you said. If that is the case, then a derived method might not hide a base class method if the parameter list is seriously incompatible. That is a natural and welcome consequence of type based dispatch. Classes are for implementation sharing, not for transitive typing. I'm talking about non-multi's here. More interestingly, left-to-right ordering of multiply-inherited base classes will be checked for applicability rather than arbitrarily taking the leftmost. Indeed, I would hope that order of inheritance doesn't matter. Sounds more role-like, now that you mention it. Regards, TSa.
Re: method hiding (or not) in derived classes
On Sat, Apr 19, 2008 at 08:00:07AM -, John M. Dlugosz wrote: : Perl 6 has a concept of a candidate list. The candidate list are those that could handle the call, typically inherited methods and multi variations. : : It seems that multi variations, at least with respect to the semicolon parameters, compare the actual type and drop out of the list if any don't match. When you drop those candidates that can never match is mostly a matter of optimization, I suspect. : What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? For those parameters, it matters only whether they can be bound when the candidate is called. The parameters need not be considered at all when generating the candidate list (but see optimization above--though perhaps this view is oversimplified if we have to do tie determination, since ties are supposed to fail before the final call, and we'd have to weed out non-bindable sigs before declaring a tie). : If that is the case, then a derived method might not hide a base class method if the parameter list is seriously incompatible. More interestingly, left-to-right ordering of multiply-inherited base classes will be checked for applicability rather than arbitrarily taking the leftmost. only methods use only short name, and methods, like subs, default to only. And as it is currently specced, the class is dispatched on the short name before any any of its multis, and long names are not considered until the class is dispatched to. The invariant is that single dispatch is always under the control of the invocant's object system, while multiple dispatch never is. In my mind the policy distinction is clarified by considered what happens if a foreign language defines some of the classes. Under single dispatch the language that defined the object gets the dispatch. Under multiple dispatch, all objects are treated as Perl objects with Perl types, and the type system gets to decide which candidate to call. It is important to be able to look at a call and determine which kind of call is being made; this is why we give single dispatch a syntax that is distinct from multiple dispatch. So if you use multi method declarations within a class, they appear only to be a single method from outside the class, because that is all the foreign language interface can support. You can only use multi methods within a class if the language supports the concept, and Perl 6 only supports it out the scope of the current class. Basically, multi methods are just treated as multi subs inside a class, except the invocant is predecided and doesn't make any difference to the dispatch within the class. Larry
Re: method hiding (or not) in derived classes
HaloO, John M. Dlugosz wrote: TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: Candidate set would be a better term. It is a subset of all long names of a multi in a lexical scope. List, not set, because it is ordered. nextsame/nextwith/etc. are described as invoking the next candidate on the list. Therefore, there is a list. Hmm, the term candidate should be after the applicability check and before specificity check. The latter results in a partially ordered list of targets. If there's more than one most specific target, we have an ambiguity error. As a consequence there might not be a unique next method on the target list and a nextsame might fail. I agree that the synopsis conflate these details into the term candidate list. But I hope you are more rigorous. What about ordinary methods (and ordinary parameters of multis)? Does the candidate list hold every method name that matches, or does it do simpler parameter matching based on number of arguments, required named arguments, etc.? There is hopefully a complete specification what constitutes applicability. There can hardly be differing simpler versions. In other words there is only one subtype relation that is used whenever a binding takes place. I have no idea what you said. OK, here's my vision of dispatch. First there's a syntactic distinction between MMD and class dispatch. $obj.meth(|$args); meth $obj: |$args; These pull out the candidate set from $obj. Everything else collects the candidate set from a namespace scan. Next, all candidates are checked to allow a binding of $obj and |$args. The ones that fail are dropped. If the candidate set is now empty we have a failure. The remaining set is now sorted into a list of sets by applying the subtype relation in the dispatch relevant parameter positions. If the first element of that list is a set with a single element we have a successful dispatch. Otherwise there's an ambiguity error. The .? avoids the no target error, .+ avoids the ambiguity error and .* never fails. I would leave the order in which sets of targets are called unspecified. If one needs more control the .WALK method can be used. If class dispatch fails because there's no applicable method then a MMD is attempted. I guess the answer to your question concerning hiding a method in a derived class depends on the set of candidates the $obj.HOW comes up with in the first step. If it delivers superclass methods and subclass methods fail the applicability test then the dispatch goes to a superclass method that can handle the dispatch. Would you favor a type error then? If that is the case, then a derived method might not hide a base class method if the parameter list is seriously incompatible. That is a natural and welcome consequence of type based dispatch. Classes are for implementation sharing, not for transitive typing. I'm talking about non-multi's here. Me too. As stated above the candidate set is up to the class that created the object. If this class can prevent the failover to MMD I don't know. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Re: WTF? - Re: method calls on $self
I'd have to agree.
I also think that .foo should always mean $_.foo in methods, without causing
any errors if $?SELF =:= $_ becomes false.
OK. There is a lot of historical threads on the subject and already a lot of
legacy in the Perl6 language.
OK - As I understand it, this is what A12 says:
class Foo {
# normal instance variables
has $.x;
has $.y is rw;
has $:z;
has @.foo is rw;
has @:bar
has %.baz is rw;
has %:ber
method one { return 1 }
method :two { return 2 }
# some class variables
our $.class_var1;
our $:class_var2;
our $.class_var3 is rw;
my $.class_var1_visible_only_to_class;
my $:class_var2_visible_only_to_class;
# implicit object set in $?SELF
method grr {
$.x = 1;
$.y = 2;
$:z = 3;
push @.foo, 'item';
push @:bar, 'item';
%.bazkey = 'val';
%:berkey = 'val';
my $a = .one; # hmmm - here is the subject of all of our pain
my $b = .:two;
}
# explicit object
method roar ($obj:) {
$.x = 1;
$.y = 2;
$:z = 3;
push @.foo, 'item';
push @:bar, 'item';
%.bazkey = 'val';
%:berkey = 'val';
my $a = $obj.one;
my $b = $obj.:two;
}
}
# external use of object
sub squawk ($obj) {
$obj.x = 1; # fails - no accessors
$obj.y = 2; # ok - lvalue accessor was created for us because of is rw
$obj.:z = 3; # fails - no public accessors - even if is rw
push $obj.foo, 'item'; # ok - lvalue accessor created
push $obj.bar, 'item'; # fails - even if is rw
$obj.bazkey = 'val'; #ok - lvalue
$obj.berkey = 'val'; # fails - even if is rw
my $a = $obj.one;
my $b = $obj.two;
}
Somebody correct me if I had things wrong up above.
So in all of that example, all of the instance variables and methods are
easily accessed and almost all of the rules are clear cut. So under this
final proposal we now have the following:
class Foo {
has @.elems;
method rock {
.wizbang; # called on $?SELF - looks ambiguous (what is $_)
.foo for @.elems; # fails with an error - ambibuous compared to .wizbang
}
method stone ($obj) {
$obj.wizbang;
.foo for $obj.elems; # supposedly fails ($_ no longer =:= $?SELF) :(
}
}
sub conglomerate_solid ($obj) {
$obj.wizbang;
.foo for $obj.elems; # ok here
}
sub petra ($obj) {
temp $_ = $obj;
.wizbang;
.foo for .elems; # confusing - but ok (called on different objects)
}
I don't think the most recent proposal (er edict) is really all that friendly.
I've been hoping that it is a case of linguist/architect/benevolent president
turned psychologist and that it is a foot in the door approach of getting
both sides of the ./method argument to just give up and be quiet.
This latest proposal seems to add ambiguity all in favor of getting rid of a
slash. Looking at all of the instance variables and method accesses in the
method grr up above, a method call of my $a = ./one really isn't that out
of place. Once the object is explicit, then all method calls change
(including the private ones) while all of the instance variables stay the
same.
I think that .method == $_.method needs to always hold true. I still think it
would be nice - though not as important to have ./method (or whatever
variation you want) work inside methods. I don't think that $_ should ever
default to the invocant ($_ =:= $?SELF) (which should be easy enough with
method a ($_) { ... }).
method concrete {
./wizbang;
.foo for @.elems;
.foo for ./elems; # possibly odd looking - but not confusing
}
Please, lets pick something sane. Here I go speaking for the list, but I
don't think we will find many that think .method syntax breaks in methods if
$_ is rebound as a very sound concept.
Paul
Re: WTF? - Re: method calls on $self
On Thu, July 14, 2005 10:47 am, Autrijus Tang said: If this were a straw poll, I'd say... 1. Meaning of $_ .method should mean $_.method always. Making it into a runtime error is extremely awkward; a compile-time error with detailed explanataion is acceptable but suboptimal. 2. Topicalization of $?SELF Neutral on this -- I can argue bothways. in my limited experience of writing p6 code, it is convenient but somewhat confusing to topicalize the invocant. 3. Shorthand of $?SELF.method I find ./method to be very useful in practice, and my brain gets use to it rather quickly. The association to pattern matching and division gradually fades away, at which time its novelty cease to be a problem. I have been watching perl6-language from afar and not really contributing. But I have to say that in this case I do agree with Autrijus Graham.
Re: WTF? - Re: method calls on $self
On 7/14/05, Larry Wall [EMAIL PROTECTED] wrote: Certainly. The problem is that there are too many viable alternatives, and half of everyone hates half of the alternatives. You will know I'm no longer a benevolent dictator when I start to enjoy watching people squirm every time I change my mind. Well, you've certainly got everyone flustered enough that they'll be overjoyed even if you pick the alternative they hated the most... :-) Aankhen
Re: WTF? - Re: method calls on $self
Aankhen skribis 2005-07-14 12:39 (+0530): Well, you've certainly got everyone flustered enough that they'll be overjoyed even if you pick the alternative they hated the most... :-) It's just a Solomon judgement situation. That can work out well, but I really hate when it's forced and used to test patience. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
On 7/14/05, Juerd [EMAIL PROTECTED] wrote: It's just a Solomon judgement situation. That can work out well, but I really hate when it's forced and used to test patience. If Juerd is right about this being a solomonian situation, let me just give up my baby to the other woman by saying: * It's hers. It's not important what syntax you give it. `./` is ok, but I trust @larry to make the right choice there. * Please don't hurt my baby. Let `.foo` still mean `$_.foo`, unconditionally. That's all that really matters. // Carl
Re: WTF? - Re: method calls on $self
If this were a straw poll, I'd say... 1. Meaning of $_ .method should mean $_.method always. Making it into a runtime error is extremely awkward; a compile-time error with detailed explanataion is acceptable but suboptimal. 2. Topicalization of $?SELF Neutral on this -- I can argue bothways. in my limited experience of writing p6 code, it is convenient but somewhat confusing to topicalize the invocant. 3. Shorthand of $?SELF.method I find ./method to be very useful in practice, and my brain gets use to it rather quickly. The association to pattern matching and division gradually fades away, at which time its novelty cease to be a problem. Thanks, /Autrijus/ pgpyMrTt9ljfK.pgp Description: PGP signature
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 05:37:38PM +0200, Carl Mäsak wrote: On 7/14/05, Juerd [EMAIL PROTECTED] wrote: It's just a Solomon judgement situation. That can work out well, but I really hate when it's forced and used to test patience. If Juerd is right about this being a solomonian situation, let me just give up my baby to the other woman by saying: * It's hers. It's not important what syntax you give it. `./` is ok, but I trust @larry to make the right choice there. * Please don't hurt my baby. Let `.foo` still mean `$_.foo`, unconditionally. That's all that really matters. Yes, let .foo still mean $_.foo, unconditionally, please. The `./` is nice, but I'm willing to give up the syntax in favor of letting .foo always mean $_.foo. Autrijus joked? about $?.method once (instead of ./method), in case we need any more bad alternatives for $?SELF.method. But I also trust @larry, or %larry, or even $larry, to make a decent choice that will serve the community well. So long as .foo (pretty please) means $_.foo all the time (with sugar on top?). -kolibrie
Re: WTF? - Re: method calls on $self
Nathan Gray skribis 2005-07-14 12:55 (-0400): Autrijus joked? about $?.method once (instead of ./method), in case we need any more bad alternatives for $?SELF.method. But I also trust @larry, or %larry, or even $larry, to make a decent choice that will serve the community well. Would this mean that $? is an alias for $?SELF, or only that $?. comes in ./'s stead? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Method Resolution Order question
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote: : The way I am viewing the notion of current class for submethods : currently is: : : From inside another method or submethod: : : - a submethod should only be called from the class which defines it. This doesn't sound right to me. There is no distinction between inside or outside. A submethod is simply a method that says These aren't the droids you're looking for if you call it via either SMD or MMD dispatch and the first invocant isn't of the exact run-time type of the lexical class. In other words, it just has an implicit next METHOD if $?SELF != $?CLASS; at the front. So the dispatch continues until it finds either a submethod that does have an exact match or a method that isn't a submethod. : This means that since Object::bless() calls Object::BUILDALL() it is : all well and good, assuming you have not overridden bless() in your : class, and are calling it $class.bless(). No, Object::bless() (which perhaps delegates to Class.meta.bless so that different meta classes can have different .bless primitives) calls MyClass.CREATE to create the type, while will be an opaque type if that normal method dispatch runs up the tree to Object::CREATE. (But user classes are allowed to define their own CREATE method to create non-opaque objects.) After the storage is allocated, .meta.bless then calls $newobj.BUILDALL as an ordinary method call on the instance. Again this is overridable by each class, but typically goes back to Object::BUILDALL (which, as usual, probably delegates at least some of the work to the meta class). : (Object::BUILDALL of course then digs into the metaclass to call : BUILD() for all the superclasses in post-order. I am not sure how to do : that otherwise, submethod or not.) I believe there's pseudo-code for that in A12. The trick is that you can always force a call to a submethod of the wrong class by taking it as a sub reference and calling it like an ordinary subroutine. : However, if you define MyClass::bless, then you will need to define : MyClass::BUILDALL as well. We did not intend that people redefined .bless. It's really intended to be a primitive like .meta. The occasional redefinables are CREATE and BUILDALL, but it's really only intended that BUILD be defined typically. : Or is it possible just do $self.Object::BUILDALL()? So can I call a : submethod from a different class if I fully qualify it? No, that would just fail. You have to do the reference casting trick to call it as an ordinary subroutine. We made that hard on purpose. : From outside a method (in user space): : : - the invocant of the submethod must be a direct instance of the class : in which the submethod is defined. No inheritance involved. : : Maybe this is too strict, though? What do you think? There is no user space distinction. You still just call a method with the ordinary dispatcher, and it still just runs down the list of dispatcher class candidates till it either finds one that's a method or finds one that is a submethod and whose class matches the object's. Of course, that's highly unlikely to match a submethod on anything but the first probe, given the usual visitation order of the standard dispatcher and the fact that virtual method calls always start with the actual run-tiem type of the object, but MMD might have a different idea about order, and the same principle still applies. Plus other dispatchers are possible. The point of a submethod is that it doesn't make sense to call it on anything other than an actual object of this type (where initialization and finalization are examples of where we basically lie about the actual type because we want the various bit of the current object treated as if they were really an ancestral class even though they aren't really). Since that's the point of a submethod, the proper place to put the constraint is on the front of the submethod itself, and let it just fail to be dispatched to if it doesn't want to be dispatched to. In general, unless you are a funny dispatcher like .*foo, you shouldn't be thinking about how you call them. : There's some kind of yes I mean : you notion in the dispatcher. It comes out in user-visible terms : in .*foo calls but not ordinary .foo calls, : : I am not familiar with .*foo calls? Can you elaborate? This is all pretty much straight from A12. : which call a submethod : only when the object is actually that type, and otherwise look for an : ancestral method of that name. : : Yes, to expand upon my above statements. The method resolution would : begin looking in the local submethod table, then move onto the local : method table, and then on up the superclass hierarchy. Is that correct? There is no separate submethod table. From the standpoint of ordinary .foo method resolution they're ordinary methods that happen to say next METHOD as a form of failure. The dispatcher doesn't even have to know they failed because they
Re: Method Resolution Order question
Larry,
Thanks for the detailed reply. Just a few more questions and I think I
can get this into the metamodel :)
On Jul 14, 2005, at 3:40 PM, Larry Wall wrote:
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote:
: The way I am viewing the notion of current class for submethods
: currently is:
:
: From inside another method or submethod:
:
: - a submethod should only be called from the class which defines it.
This doesn't sound right to me. There is no distinction between
inside or outside.
Yes, I am not sure what I was thinking there. Shortly after I wrote
this mail I did some work on submethods in the metamodel and realized
how silly that idea is :)
I also realized that a sepereate submethod dispatch table made no sense
either, so scratch that thought out as well.
A submethod is simply a method that says These
aren't the droids you're looking for if you call it via either SMD
or MMD dispatch and the first invocant isn't of the exact run-time
type of the lexical class. In other words, it just has an implicit
next METHOD if $?SELF != $?CLASS;
at the front. So the dispatch continues until it finds either a
submethod
that does have an exact match or a method that isn't a submethod.
Now, the metamodel currently does not have MMD, and I think next
METHOD is not as relevant in SMD. So would it make sense to do:
next SUPER if $?SELF != $?CLASS;
or something like that? Here is some example code which might encounter
this:
class Foo {
method baz { ... }
}
class Bar is Foo {
submethod baz { ... }
}
class FooBar is Bar {}
my $foo_bar = FooBar.new();
$foo_bar.baz() # calls Foo::baz()
basically the dispatch goes from Bar::baz, which says next SUPER and
the dispatcher then goes to Foo::baz since it is a method.
Is that correct?
: This means that since Object::bless() calls Object::BUILDALL() it is
: all well and good, assuming you have not overridden bless() in your
: class, and are calling it $class.bless().
No, Object::bless() (which perhaps delegates to Class.meta.bless so
that different meta classes can have different .bless primitives)
Okay, this makes sense.
calls MyClass.CREATE to create the type, while will be an opaque type
if that normal method dispatch runs up the tree to Object::CREATE.
(But user classes are allowed to define their own CREATE method to
create non-opaque objects.)
After the storage is allocated, .meta.bless then calls $newobj.BUILDALL
as an ordinary method call on the instance. Again this is overridable
by each class, but typically goes back to Object::BUILDALL (which, as
usual, probably delegates at least some of the work to the meta class).
You refer to CREATE and BUILDALL as methods here, but A12 calls them
submethods. Which is correct?
: (Object::BUILDALL of course then digs into the metaclass to call
: BUILD() for all the superclasses in post-order. I am not sure how to
do
: that otherwise, submethod or not.)
I believe there's pseudo-code for that in A12. The trick is that you
can always force a call to a submethod of the wrong class by taking
it as a sub reference and calling it like an ordinary subroutine.
Okay, this is just as dirty a trick as sneaking up into the metamodel,
so I will leave it that way for now, knowing I need to change it later
:)
: However, if you define MyClass::bless, then you will need to define
: MyClass::BUILDALL as well.
We did not intend that people redefined .bless. It's really intended
to be
a primitive like .meta. The occasional redefinables are CREATE and
BUILDALL,
but it's really only intended that BUILD be defined typically.
Agreed, .bless should probably never be redefined, I will pull that up
into the MetaClass.
snip
: There's some kind of yes I mean
: you notion in the dispatcher. It comes out in user-visible terms
: in .*foo calls but not ordinary .foo calls,
:
: I am not familiar with .*foo calls? Can you elaborate?
This is all pretty much straight from A12.
I see now, I forgot about those :)
: which call a submethod
: only when the object is actually that type, and otherwise look for
an
: ancestral method of that name.
:
: Yes, to expand upon my above statements. The method resolution would
: begin looking in the local submethod table, then move onto the local
: method table, and then on up the superclass hierarchy. Is that
correct?
There is no separate submethod table. From the standpoint of ordinary
.foo method resolution they're ordinary methods that happen to say
next METHOD as a form of failure.
Yup, realized that as soon as I tried to implement it :)
Thanks,
Stevan
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
it'll always be construed as unambigous. You could go so far as to
say
method foo($x) {
my $y = .bar; # $_ is self call because $_ := $?SELF
given $y { use dot; # yes I know what I'm doing
when 1 { .abc } # calls $y.abc
when 2 { .bcd } # calls $y.bcd
}
.baz; # back to self.baz
}
It's a little klunky but does localize the override rather visibly.
Doubtless people will generally put the use dot at the front though.
Larry
Re: Method Resolution Order question
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: A submethod is simply a method that says These
: aren't the droids you're looking for if you call it via either SMD
: or MMD dispatch and the first invocant isn't of the exact run-time
: type of the lexical class. In other words, it just has an implicit
:
: next METHOD if $?SELF != $?CLASS;
:
: at the front. So the dispatch continues until it finds either a
: submethod
: that does have an exact match or a method that isn't a submethod.
:
: Now, the metamodel currently does not have MMD, and I think next
: METHOD is not as relevant in SMD. So would it make sense to do:
:
: next SUPER if $?SELF != $?CLASS;
:
: or something like that?
It comes out to that under single inheritance, but under MI it might
well be that the next method that ought to be called is actually a
sibling method.
: Here is some example code which might encounter this:
:
: class Foo {
: method baz { ... }
: }
:
: class Bar is Foo {
: submethod baz { ... }
: }
:
: class FooBar is Bar {}
:
: my $foo_bar = FooBar.new();
: $foo_bar.baz() # calls Foo::baz()
:
: basically the dispatch goes from Bar::baz, which says next SUPER and
: the dispatcher then goes to Foo::baz since it is a method.
:
: Is that correct?
It says next METHOD, which has the same effect under SI. But we don't
know whether we're under MI, and we don't know if the dispatcher we're
working under has some weird order of visitation, so it's clearer to
say next METHOD and leave it up to the dispatcher to decide if the
SUPER is the next method. It *usually* is, but...
: You refer to CREATE and BUILDALL as methods here, but A12 calls them
: submethods. Which is correct?
The default versions are methods so that they can be inherited. The
individual versions defined by classes are submethods unless they intend
to be inherited, and force all their subclasses into a new set of default
sematics. And they're always called as methods (except when things like
.* cheat).
: I believe there's pseudo-code for that in A12. The trick is that you
: can always force a call to a submethod of the wrong class by taking
: it as a sub reference and calling it like an ordinary subroutine.
:
: Okay, this is just as dirty a trick as sneaking up into the metamodel,
: so I will leave it that way for now, knowing I need to change it later
: :)
Of course, the metamodel can do whatever dirty tricks it likes,
but in Perl 6 the metamodel might actually implement this particular
operation by forcing a sub call through a reference, if the metamodel
is implemented in Perl 6. It's the only way we've defined to
defeat the .foo dispatcher so far, from a language point of view.
(Though simply calling .meta could also be construed as cheating,
I guess. Or at least an authorization of cheating on your behalf.)
Larry
Re: Method Resolution Order question
Larry,
Thanks much, this all makes sense. :)
Thanks,
Stevan
On Jul 14, 2005, at 4:54 PM, Larry Wall wrote:
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: Now, the metamodel currently does not have MMD, and I think next
: METHOD is not as relevant in SMD. So would it make sense to do:
:
: next SUPER if $?SELF != $?CLASS;
:
: or something like that?
It comes out to that under single inheritance, but under MI it might
well be that the next method that ought to be called is actually a
sibling method.
This is just to clarify for me (and anyone else paying attention),
because this made more sense when I saw it.
class Foo {
method baz { ... }
}
class Bar {
submethod baz { ... }
}
class FooBar is Foo is Bar {}
my $foo_bar = FooBar.new();
$foo_bar.baz() # calls Foo::baz()
No need to respond unless I got it wrong :)
: Here is some example code which might encounter this:
:
: class Foo {
: method baz { ... }
: }
:
: class Bar is Foo {
: submethod baz { ... }
: }
:
: class FooBar is Bar {}
:
: my $foo_bar = FooBar.new();
: $foo_bar.baz() # calls Foo::baz()
:
: basically the dispatch goes from Bar::baz, which says next SUPER
and
: the dispatcher then goes to Foo::baz since it is a method.
:
: Is that correct?
It says next METHOD, which has the same effect under SI. But we
don't
know whether we're under MI, and we don't know if the dispatcher we're
working under has some weird order of visitation, so it's clearer to
say next METHOD and leave it up to the dispatcher to decide if the
SUPER is the next method. It *usually* is, but...
: You refer to CREATE and BUILDALL as methods here, but A12 calls them
: submethods. Which is correct?
The default versions are methods so that they can be inherited. The
individual versions defined by classes are submethods unless they
intend
to be inherited, and force all their subclasses into a new set of
default
sematics. And they're always called as methods (except when things
like
.* cheat).
: I believe there's pseudo-code for that in A12. The trick is that
you
: can always force a call to a submethod of the wrong class by
taking
: it as a sub reference and calling it like an ordinary subroutine.
:
: Okay, this is just as dirty a trick as sneaking up into the
metamodel,
: so I will leave it that way for now, knowing I need to change it
later
: :)
Of course, the metamodel can do whatever dirty tricks it likes,
but in Perl 6 the metamodel might actually implement this particular
operation by forcing a sub call through a reference, if the metamodel
is implemented in Perl 6. It's the only way we've defined to
defeat the .foo dispatcher so far, from a language point of view.
(Though simply calling .meta could also be construed as cheating,
I guess. Or at least an authorization of cheating on your behalf.)
Larry
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 01:39:44PM -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
If .method always means $_.method ($_ being the topic) then I don't see how
it is ever ambiguous. Unless I missed where nested loops would also
disallow .method because people might not be able to keep track of the
topic.
use dot;
it'll always be construed as unambigous. You could go so far as to
say
method foo($x) {
my $y = .bar; # $_ is self call because $_ := $?SELF
given $y { use dot; # yes I know what I'm doing
when 1 { .abc } # calls $y.abc
when 2 { .bcd } # calls $y.bcd
}
.baz; # back to self.baz
}
Why must anything special be done in the given block to allow .method if
it is always $_.method? Since I know $y is the topic in this block I know
to expect $y.abc to be called. There is no ambiguity. An error here
would just be confusing.
Now, for those who want .abc to call $?SELF.abc within the given block
then I think it would be clearer if they spelled out that intention with
something like
given $y { use dot '$?SELF'; # or just 'use dot' with suitable default
when 1 { .abc } # calls $?SELF.abc
}
--
Rick Delaney
[EMAIL PROTECTED]
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
ICK! TOO MANY CHOICES!
If we have pragmas for the 99 Perl6's that every wacko wants to
have, we won't have any readability.
The syntax needs to be consistent and useful, even at the price of
some danger.
I don't want to be using a language designed for idiots - I know
what I'm doing, and I like the power that perl 5 has given me.
How many times have you typed
map { chr }
map { lc }
grep { defined }
and then got bummed out that you can't have
grep { .is_moose }
since it's in a method.
That really sucks.
I'd rather have '.foo' not work on $?SELF at all than have that.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
pgpaUXI5Wijpd.pgp
Description: PGP signature
Re: WTF? - Re: method calls on $self
Larry Wall skribis 2005-07-14 13:39 (-0700): On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote: : So long as .foo (pretty please) means $_.foo all the time (with sugar on : top?). It means that all the time, but only when unambiguous. Thus it never means $?SELF.foo without $_ being the same thing, and thus it always means $_.foo, and thus there is no ambiguity about what .foo means, and .foo can mean $_.foo even if $_ isn't $?SELF, as $?SELF is never a factor in the decision what .foo means. Good, glad that's solved. We have normality. It's a little klunky but does localize the override rather visibly. Doubtless people will generally put the use dot at the front though. Doubtless if you really insist on this feature, Perl 6 will see its first fork very shortly after its release... But have no fear, because it will run all standard Perl 6 code too, as the thing that the fork introduces used to be an error. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
Yuval Kogman skribis 2005-07-15 1:09 (+0300): use dot; If we have pragmas for the 99 Perl6's that every wacko wants to have, we won't have any readability. The syntax needs to be consistent and useful, even at the price of some danger. Agreed. I don't want to be using a language designed for idiots - I know what I'm doing, and I like the power that perl 5 has given me. Me too. I'd rather have '.foo' not work on $?SELF at all than have that. .foo never working on $?SELF is consistent with the initial design, the idea that the default variable is always $_ (as explained very well by Damian), and the design until a few days ago. I really do not understand why Larry has changed his mind about .foo, as the meaning of .foo has not been topic of discussion for a long time now. The syntax of ./foo did receive a lot of both negative and positive attention, and I could understand that ./foo, being found ugly by some people, would be pulled out of the language in favour of some yet to invent syntax, or perhaps without replacement. That, however, has nothing to do with .foo. Or at least HAD nothing to do with .foo, until Larry decided that if $_ := $?SELF, .foo would be special all of a sudden. If that is so, then lc without arguments would also need to be special, as that also defaults to $_, which would then be the same thing as $?SELF, which makes things special. lc without arguments would also need to be forbidden, following this way of thinking. We can only hope our dictator turns benevolent again, at least regarding the one thing we all agree about (and have agreed about for quite some time): that .foo must always mean $_.foo. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
On Fri, Jul 15, 2005 at 01:09:57AM +0300, Yuval Kogman wrote: On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote: On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote: : So long as .foo (pretty please) means $_.foo all the time (with sugar on : top?). It means that all the time, but only when unambiguous. If you say use dot; I'd rather have '.foo' not work on $?SELF at all than have that. Um, that's what I was hoping for too. Let .foo mean $_.foo, and never $?SELF.foo, unless of course $_ happens to contain $?SELF at that moment. (sugar, anyone?) -kolibrie
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 09:38:45PM +0200, Juerd wrote: Nathan Gray skribis 2005-07-14 12:55 (-0400): Autrijus joked? about $?.method once (instead of ./method), in case we need any more bad alternatives for $?SELF.method. But I also trust @larry, or %larry, or even $larry, to make a decent choice that will serve the community well. Would this mean that $? is an alias for $?SELF, or only that $?. comes in ./'s stead? The former. But this is strictly a joke in response to nothingmuch's two characters shorthand criteria on #perl6; please don't hold it against me, or invoke the famed joke-turned-into-reality p6l device! :) Thanks, /Autrijus/ pgpiqjSf1TXa2.pgp Description: PGP signature
Re: Method Resolution Order question
On Wed, Jul 13, 2005 at 12:51:49PM -0400, Stevan Little wrote:
: Hello,
:
: More questions for the metamodel. I am trying to add proper submethod
: and private method handling and I have a question about method
: resolution order as a whole. I asked a similar question last week, but
: this time I have more details :)
:
: Given this class:
:
: class Foo {
: submethod bar { ... }
: method bar { ... }
: }
:
: and given this code:
:
: Foo.new().bar()
:
: What should happen?
:
: The Syn/Apoc seem to indicate that methods and submethods of the same
: name can coexist. So the class definition itself is legal. However, it
: brings up an issue when it comes time to call bar().
If the Syn/Apoc is giving that impression, it's giving the wrong impression.
Subs, methods, and anything in between all live in the same namespace.
The class above is illegal because you're trying to give two things
the name bar in the absence of a multi.
: Should submethod bar() be called first, then method bar() after it?
: Should method bar() be called first, then submethod bar() after it?
Question doesn't arise.
: Can submethods only be called from within the class (like private
: methods)?
No, they can be called from anywhere. They're just constrained to
work only when a dispatcher's idea of current class matches the
actual class, where current class usually means the actual class
of the object in question, but can also mean an ancestral class when
we're doing BUILDALL, for instance. There's some kind of yes I mean
you notion in the dispatcher. It comes out in user-visible terms
in .*foo calls but not ordinary .foo calls, which call a submethod
only when the object is actually that type, and otherwise look for an
ancestral method of that name.
: And if submethods can only be called from within the class, then how do
: I handle this:
:
: class Foo {
: submethod bar { ... }
: method bar { ... }
: method baz {
: $?SELF.bar()
: }
: }
:
: Foo.new().baz()
Again, illegal class.
: Thanks,
:
: Stevan
:
Re: WTF? - Re: method calls on $self
On Tue, Jul 12, 2005 at 04:43:06PM +0530, Aankhen wrote: : I agree with what is being said here. `.method` is a great way to : eliminate a lot of repetitive, tedious typing. Surely there is a : viable alternative that doesn't involve outlawing it? Certainly. The problem is that there are too many viable alternatives, and half of everyone hates half of the alternatives. You will know I'm no longer a benevolent dictator when I start to enjoy watching people squirm every time I change my mind. Larry
Re: Method Resolution Order question
Larry, On Jul 13, 2005, at 2:30 PM, Larry Wall wrote: : The Syn/Apoc seem to indicate that methods and submethods of the same : name can coexist. So the class definition itself is legal. However, it : brings up an issue when it comes time to call bar(). If the Syn/Apoc is giving that impression, it's giving the wrong impression. Subs, methods, and anything in between all live in the same namespace. The class above is illegal because you're trying to give two things the name bar in the absence of a multi. Horray : Can submethods only be called from within the class (like private : methods)? No, they can be called from anywhere. They're just constrained to work only when a dispatcher's idea of current class matches the actual class, where current class usually means the actual class of the object in question, but can also mean an ancestral class when we're doing BUILDALL, for instance. The way I am viewing the notion of current class for submethods currently is: From inside another method or submethod: - a submethod should only be called from the class which defines it. This means that since Object::bless() calls Object::BUILDALL() it is all well and good, assuming you have not overridden bless() in your class, and are calling it $class.bless(). (Object::BUILDALL of course then digs into the metaclass to call BUILD() for all the superclasses in post-order. I am not sure how to do that otherwise, submethod or not.) However, if you define MyClass::bless, then you will need to define MyClass::BUILDALL as well. Or is it possible just do $self.Object::BUILDALL()? So can I call a submethod from a different class if I fully qualify it? From outside a method (in user space): - the invocant of the submethod must be a direct instance of the class in which the submethod is defined. No inheritance involved. Maybe this is too strict, though? What do you think? There's some kind of yes I mean you notion in the dispatcher. It comes out in user-visible terms in .*foo calls but not ordinary .foo calls, I am not familiar with .*foo calls? Can you elaborate? which call a submethod only when the object is actually that type, and otherwise look for an ancestral method of that name. Yes, to expand upon my above statements. The method resolution would begin looking in the local submethod table, then move onto the local method table, and then on up the superclass hierarchy. Is that correct? Thanks, Stevan
WTF? - Re: method calls on $self
Larry Wall skribis 2005-07-11 18:29 (-0700):
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
What?
That makes having a default at all useless, it makes moving code without
breaking it impossible again, it requires a lot of extra typing with
shifted keys, it adds an arbitrary looking exception, and it is wildly
undwimmy and impractical, and thus unperlish by every definition I know.
This is, by far, the silliest solution for this problem that I have seen
proposed, because it is a combination of almost all the cons, and comes
at a time in which all the pros and cons of other solutions are already
known and discussed.
That's the default, and I'm not changing my mind ever again, at least
till next week.
I can wait till next week.
use self this;
use self self;
use self o;
use self ./;
use self ;
Any of these must be the default, and frankly I do not care much which
one it is, if that means the current non-solution goes away.
Obviously, use self is the least attractive of these, but I would
still prefer it to outlawing .foo.
If the default isn't sane, the language isn't sane. That there is a
pragma to change things, should never be a reason to stop picking good
defaults.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
No, but I do refactor. I do add loops and methods around existing code.
I do use for (or given in p6) to topicalize, to be able to type LESS.
In Perl 5, I really hate
for ($object) {
$_-method(...);
$_-method(...);
$_-method(...);
}
And the Perl 6 equivalent until your revelation,
given $object {
.method(...);
.method(...);
.method(...);
}
was the perfect solution. Killing off a useful and much used idiom even
before the first release is quite an accomplishment.
Disallowing .method here means a huge step back in time. Back to
$_.method or $object.method.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
I feel a me too post is in order.
I've written code that is 2-3 levels of nested given/when in a
method of an object that wasn't the topic.
I did not feel confused at all, juggling .foo and ./foo, which are
visually distinct, and different to type. They convey a big
difference of meaning, even if it's only 1 char apart.
I think a solution to the problem of being able to use those two
well, is not a solution, because there isn't a problem.
On Tue, Jul 12, 2005 at 12:59:22 +0200, Juerd wrote:
Larry Wall skribis 2005-07-11 18:29 (-0700):
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
What?
That makes having a default at all useless, it makes moving code without
breaking it impossible again, it requires a lot of extra typing with
shifted keys, it adds an arbitrary looking exception, and it is wildly
undwimmy and impractical, and thus unperlish by every definition I know.
This is, by far, the silliest solution for this problem that I have seen
proposed, because it is a combination of almost all the cons, and comes
at a time in which all the pros and cons of other solutions are already
known and discussed.
That's the default, and I'm not changing my mind ever again, at least
till next week.
I can wait till next week.
use self this;
use self self;
use self o;
use self ./;
use self ;
Any of these must be the default, and frankly I do not care much which
one it is, if that means the current non-solution goes away.
Obviously, use self is the least attractive of these, but I would
still prefer it to outlawing .foo.
If the default isn't sane, the language isn't sane. That there is a
pragma to change things, should never be a reason to stop picking good
defaults.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
No, but I do refactor. I do add loops and methods around existing code.
I do use for (or given in p6) to topicalize, to be able to type LESS.
In Perl 5, I really hate
for ($object) {
$_-method(...);
$_-method(...);
$_-method(...);
}
And the Perl 6 equivalent until your revelation,
given $object {
.method(...);
.method(...);
.method(...);
}
was the perfect solution. Killing off a useful and much used idiom even
before the first release is quite an accomplishment.
Disallowing .method here means a huge step back in time. Back to
$_.method or $object.method.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: uhm, no, I think I'll sit this one out..: neeyah!
pgpL6XkyQ00ZQ.pgp
Description: PGP signature
Re: WTF? - Re: method calls on $self
On 7/12/05, Juerd [EMAIL PROTECTED] wrote: [snip] Disallowing .method here means a huge step back in time. Back to $_.method or $object.method. [snip] I agree with what is being said here. `.method` is a great way to eliminate a lot of repetitive, tedious typing. Surely there is a viable alternative that doesn't involve outlawing it? Aankhen
Re: How to write a self.pm (Re: method calls on $self)
Autrijus Tang wrote:
The compiler, in turn inspect whether there's an bound $_ in scope
with $?SELF set. It is not trivial, because this should work:
sub baz (c) { c() }
method foo { baz { .bar } } # $_ is free in inner closure
But this needs to fail:
sub baz (c) { c(1) }
method foo { baz { .bar } } # $_ is bound in inner closure
I might still not understand topic, $_ or lexical vars in general.
But why does the fact that c is called with a parameter
in the second case and without one in the first example make a
difference? Isn't $_ always coming in out of band? So .bar is always
invoked on the invocant of foo if we think that there is an implicit
$_ := $?SELF before the call to baz in foo. And I hope the binding
of $_ to $?SELF is a read-only binding!
--
TSa (Thomas Sandlaß)
Re: How to write a self.pm (Re: method calls on $self)
On Tue, Jul 12, 2005 at 12:36:23PM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote:
: On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: : On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: : The obvious thought is to have yet another magical, $^H like flag, to
: : denote the current dialect. If it is set, then the parser can emit
: : .method as $_.method, instead of $?IMPLICIT_INVOCANT.method.
:
: The parser always emits .method as $_.method under any dialect, or
: fails. What has changed is whether $_ sometimes means the invocant.
:
: But the compiler needs to trigger ambiguity resolution -- i.e. check
: for $?SELF agreement with $_ -- when it sees $?IMPLICIT_INVOCANT.
:
: No need to do that if it sees $_.method. So they need to be different.
Well, another approach is to treat .method as invariably $_.method,
and catch the problem at the attempt to rebind $_. Thomas seems to
think it should already be doing that. Of course, that would make it
impossible to use given or for inside a method at all...
So the other approach is to give up on compile-time checks and say
that $?IMPLICIT_INVOCANT.method in a method's lexical scope (and
in the absence of use self) turns into
($_ =:= $?SELF ?? $_.method :: fail Phooey)
: In any event, SMD methods always have a first argument, so you're never
: in doubt at that point. And since .bar always means $_.bar, I don't
: think you really have a problem here that's any harder than you already
: had with $_.
:
: The problem here is for the compiler to detect whether $_ agrees
: with $?SELF, when it sees $?IMPLICIT_INVOCANT. If they agree,
: $?IMPLICIT_INVOCANT gets replaced by $_; otherwise it is an error.
:
: Consider this construct:
:
: method foo {
: $_ := $something_else if rand(2)1;
: .bar;
: }
:
: That's one case where it's not possible to detect at compile time,
: so it needs to silently let .bar go thru as $_.bar.
Though Thomas's constant binding notion would presumably catch that.
But then we're getting into the noalias zone that Dennis Ritchie hates.
On the other hand, I can see lots of uses for variables that may
not be rebound, at least in terms of reassuring the optimizer that
Weird Things Can't Happen.
: : Clearly we need a way to statically determine statement:given
: : and statement:for will always assign at least one argument to
: : its block argument. Without that, the compile-time analysis mandated by
: : Larry is infeasible.
:
: I think you can assume that given and for always bind at least one
: argument. In particular, a for that binds 0 arguments will never
: progress, plus you can recognize it:
:
: But what in given and for signify that? I do not want to special
: case based on function names, and statement:given may be rebound
: to something else.
I understand the desire for generality, but that road also leads to
error messages that are completely opaque to naive users, who are
pretty accurate in their view that features like given and for
will Stay Put in the normal course of events. Many of the most useful
diagnostics in Perl 5 are the ones that are guessing based on common
usage patterns. Users can't do much with messages that when deciphered
come out to mean something like you called a function passing as
its first argument another function whose first argument's declared
type allows it to be optionally bound to $_ but if we actually try to
make use of that we'll get some ambiguity further on down the road,
and that's bad. They'd much rather chuck the generality and have
You can't say .foo inside given where the topic could be either $_
or the method's invocant. Or in the absense of that just blow up
at run time.
Of course, I'm just restating your problem here...
: How does that something else signify that it will
: at least bind at least one argument to its code argument? Via the
: signature of the code argument, i.e. the Any in codeAny?
:
: sub statement:given (Any $topic, codeAny) { ... }
Maybe something like:
sub statement:given (Any $topic, *code:(Any is topic)) { ... }
: If so, what is the signature of for? I can't seem to write it down.
Good question. I suppose the signature wants to guarantee minimum arity
of 1 somehow. Maybe
sub statement:for (Lazy [EMAIL PROTECTED], *code:(Any is topic, *)) {
... }
or some such. But whether the outer function is actually functioning
as a topicalizer would still depend on the innards of your function.
Hmm. We might settle for declaring such functions with a special trait
that indicates that they are *intended* to function as topicializers.
And then maybe the compiler could just depend on those declarations
for its static analysis:
sub statement:given (Any $topic, *code:(Any)) is topicalizer { ... }
Other that that we rely on the run-time check. (Which hopefully common
code analysis can factor out multiple copies of.)
: : Then,
Re: method calls on $self
On Sat, 9 Jul 2005, Robin Redeker wrote: I wasn't thinking 'cool', I was thinking 'visually distinctive and mnemonic'. I actually think o. is cooler. Yes, i would like o. more too. At least it doesn't introduce a completly meaningless '/' preceded by a '.'. Hmmm... I am one of those who likes ./ more, instead. I mean, I _really_ like it! Thus, how about making '/' less meaningless, i.e. more meaningful, in more general situations?!? Michele -- Bunch of slack-jawed faggots around here! This stuff will make you a god damnned sexual Tyrannosaurus, just like me! - Blain, Predator (1987)
Re: method calls on $self
On Mon, Jul 11, 2005 at 11:14:18AM +0200, Michele Dondi wrote: : Hmmm... I am one of those who likes ./ more, instead. I mean, I _really_ : like it! Thus, how about making '/' less meaningless, i.e. more : meaningful, in more general situations?!? Um, do you have a specific proposal? Like maybe / can be applied as a metaoperator to any binary operator to make it into a unary operator with the left side implicitly $?SELF, or some such? Hmm... if ==/ 3# if $?SELF == 3 could even extend it to postfix ops: ++/;# $?SELF++ However, it has several problems. First, . isn't really a binary operator, but the prefix of a postfix operator. Second, the / is potentially ambiguous with a following pattern unless we require space before termish /. Third, the / is psychologically in the wrong place to stand in for something in front. Or to turn these on their head, we've just made three good arguments for something like: if o == 3 and o++; I'm afraid that, while ./ is cute and visually distinctive, I find I'm getting tired of its idiosyncracies. You shouldn't go out and marry someone just because they're cute and visually distinctive. Hooray for long engagements, and occasional disengagements. Larry
Re: method calls on $self
Larry~ On 7/11/05, Larry Wall [EMAIL PROTECTED] wrote: On Mon, Jul 11, 2005 at 11:14:18AM +0200, Michele Dondi wrote: : Hmmm... I am one of those who likes ./ more, instead. I mean, I _really_ : like it! Thus, how about making '/' less meaningless, i.e. more : meaningful, in more general situations?!? Um, do you have a specific proposal? Like maybe / can be applied as a metaoperator to any binary operator to make it into a unary operator with the left side implicitly $?SELF, or some such? Hmm... if ==/ 3# if $?SELF == 3 could even extend it to postfix ops: ++/;# $?SELF++ However, it has several problems. First, . isn't really a binary operator, but the prefix of a postfix operator. Second, the / is potentially ambiguous with a following pattern unless we require space before termish /. Third, the / is psychologically in the wrong place to stand in for something in front. Or to turn these on their head, we've just made three good arguments for something like: if o == 3 and o++; I'm afraid that, while ./ is cute and visually distinctive, I find I'm getting tired of its idiosyncracies. You shouldn't go out and marry someone just because they're cute and visually distinctive. Hooray for long engagements, and occasional disengagements. Yay! I guess I will take this moment to resuggest @^ as a list of invocants and $^ =:= @^[0]. I like how the ^ kinda points you the right way, also visually distinctive and doesn't get in the way of $_... Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: method calls on $self
On Mon, Jul 11, 2005 at 04:50:56PM -0400, Matt Fowles wrote:
: Yay! I guess I will take this moment to resuggest @^ as a list of
: invocants and $^ =:= @^[0]. I like how the ^ kinda points you the
: right way, also visually distinctive and doesn't get in the way of
: $_...
I don't see much use for @^ since multis require you to declare all
your invocants anyway. Maybe one could envision a macro that has an
unhealthy interest in innards of an unknown argument list, but that
can probably be better satisified with @?ARGS or some such.
And $^ is just too long to be a standard shortcut.
{
let $Larry.decisive = 1;
Okay, this is what we're gonna do. We're gonna go back pretty close to
where we were originally, but with a twist. That is, .foo is always
a call on the current topic, but the invocant is (again) always the
topic in the outer scope of a method. The difference from before
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
(If necessary we can also compile .foo inside methods down to code
that checks at runtime whether $_ has diverged from $?SELF and pitch
a run-time fit for those situations we can't detect at compile time.
Or we can just declare it erroneous.) Basically, you can't use .foo
inside a given or a for inside a method.
That's the default, and I'm not changing my mind ever again, at least
till next week. That being said, if you mutate your language with
anything like:
use self this;
use self self;
use self o;
use self ./;
use self ;
...
then the pragma is allowed to warp .foo semantics to make it *always*
refer to $_ everywhere, provided it *also* undoes the default binding
of $_ := $?SELF, so people that people aren't tempted to use .foo to
mean $?SELF.foo in that scope.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
Shame on you. Move the common code to a role, or a base class.
I think the lesson of the last few months is that there are some
things we'll never agree on, and we just need to make it possible
to disagree in the least disagreeable fashion. I've tried hard
to believe everyone's viewpoint on this at one point or another,
so I think I'm qualified to say that they all have their strong
points and their weak points. And that the programmer needs to
have the final say on which viewpoint they find least repulsive.
}
Larry
How to write a self.pm (Re: method calls on $self)
(Cross-posting the new ruling from p6l to p6c to discuss implementation
strategy)
On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
{
let $Larry.decisive = 1;
Okay, this is what we're gonna do. We're gonna go back pretty close to
where we were originally, but with a twist. That is, .foo is always
a call on the current topic, but the invocant is (again) always the
topic in the outer scope of a method. The difference from before
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
(If necessary we can also compile .foo inside methods down to code
that checks at runtime whether $_ has diverged from $?SELF and pitch
a run-time fit for those situations we can't detect at compile time.
Or we can just declare it erroneous.) Basically, you can't use .foo
inside a given or a for inside a method.
That's the default, and I'm not changing my mind ever again, at least
till next week. That being said, if you mutate your language with
anything like:
use self this;
use self self;
use self o;
use self ./;
use self ;
...
then the pragma is allowed to warp .foo semantics to make it *always*
refer to $_ everywhere, provided it *also* undoes the default binding
of $_ := $?SELF, so people that people aren't tempted to use .foo to
mean $?SELF.foo in that scope.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
Shame on you. Move the common code to a role, or a base class.
}
Normally, I try to comply with new rulings as soon as they become
available, but the implementation of this is nontrivial, so I'd welcome
more input.
The obvious thought is to have yet another magical, $^H like flag, to
denote the current dialect. If it is set, then the parser can emit
.method as $_.method, instead of $?IMPLICIT_INVOCANT.method. If it is
not set, the parser needs to emit this as the first statement in any
method body:
$_ := $?SELF
The compiler, in turn inspect whether there's an bound $_ in scope
with $?SELF set. It is not trivial, because this should work:
sub baz (c) { c() }
method foo { baz { .bar } } # $_ is free in inner closure
But this needs to fail:
sub baz (c) { c(1) }
method foo { baz { .bar } } # $_ is bound in inner closure
Clearly we need a way to statically determine statement:given
and statement:for will always assign at least one argument to
its block argument. Without that, the compile-time analysis mandated by
Larry is infeasible.
Then, we need to figure out the structure for the magic flag set by
self.pm on behalf of its caller. We are not using $^H anymore, so
there needs to be a way to pass lexical settings to the caller.
To use MJD's lexical pragma design:
module self;
use pragma;
sub import ($caller, $dialect) {
install_pragma_value('$?SELF_MAGICAL', $dialect);
}
This will create a lexically scoped hint in the importer's scope;
the parser and compiler will be hard-wired to recognise that magic
and act accordingly.
Does this seem sane? The static detection of $_ is the showstopper
currently, and Pugs will need to separate the compiler with PIL evaluator
to implement the pragma.pm above. Before that happens, I'll still
pretend that:
use self './';
is in scope. If people are uncomfortable with that, maybe we can
retrofit all tests and examples using the ./ syntax to add that dummy
line on top of their code, and ship with a stub self.pm that does
nothing. Will that do as a interim solution?
Thanks,
/Autrijus/
pgpN8udhQ2SUX.pgp
Description: PGP signature
Re: How to write a self.pm (Re: method calls on $self)
On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: The obvious thought is to have yet another magical, $^H like flag, to
: denote the current dialect. If it is set, then the parser can emit
: .method as $_.method, instead of $?IMPLICIT_INVOCANT.method.
The parser always emits .method as $_.method under any dialect, or
fails. What has changed is whether $_ sometimes means the invocant.
: If it is
: not set, the parser needs to emit this as the first statement in any
: method body:
:
: $_ := $?SELF
That is the part that has to be conditional on the dialect.
: The compiler, in turn inspect whether there's an bound $_ in scope
: with $?SELF set. It is not trivial, because this should work:
:
: sub baz (c) { c() }
: method foo { baz { .bar } } # $_ is free in inner closure
:
: But this needs to fail:
:
: sub baz (c) { c(1) }
: method foo { baz { .bar } } # $_ is bound in inner closure
The compiler is free to treat any undecidable binding as ambiguous
and die of uncertainty. Though we should probably make some official
rule so that different compilers don't end up with different definitions
of undecidable.
In any event, SMD methods always have a first argument, so you're never
in doubt at that point. And since .bar always means $_.bar, I don't
think you really have a problem here that's any harder than you already
had with $_.
: Clearly we need a way to statically determine statement:given
: and statement:for will always assign at least one argument to
: its block argument. Without that, the compile-time analysis mandated by
: Larry is infeasible.
I think you can assume that given and for always bind at least one
argument. In particular, a for that binds 0 arguments will never
progress, plus you can recognize it:
for @foo - {...}
And a given that doesn't bind $_ isn't worth much either.
Or is that what you're asking?
: Then, we need to figure out the structure for the magic flag set by
: self.pm on behalf of its caller. We are not using $^H anymore, so
: there needs to be a way to pass lexical settings to the caller.
Perhaps hints should just be considered lexically scoped $? variables.
You export them lexically just the same way you export any other lexically
scoped things, however that is.
: To use MJD's lexical pragma design:
:
: module self;
: use pragma;
: sub import ($caller, $dialect) {
: install_pragma_value('$?SELF_MAGICAL', $dialect);
: }
:
: This will create a lexically scoped hint in the importer's scope;
: the parser and compiler will be hard-wired to recognise that magic
: and act accordingly.
How will you handle:
use Foo :my$x;
Seems like this is just a kind of
use Foo :my$?MYHINT
thingy, only perhaps you're just setting $?MYHINT rather than aliasing
it back into a Foo variable.
: Does this seem sane? The static detection of $_ is the showstopper
: currently, and Pugs will need to separate the compiler with PIL evaluator
: to implement the pragma.pm above.
I suspect you're making it complicateder than it needs to be, but
perhaps I don't understand the problem fully. Of course, the two are
not mutually exclusive...
: Before that happens, I'll still pretend that:
:
: use self './';
:
: is in scope. If people are uncomfortable with that, maybe we can
: retrofit all tests and examples using the ./ syntax to add that dummy
: line on top of their code, and ship with a stub self.pm that does
: nothing. Will that do as a interim solution?
That's fine for the short term.
Larry
Re: How to write a self.pm (Re: method calls on $self)
On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote:
On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: The obvious thought is to have yet another magical, $^H like flag, to
: denote the current dialect. If it is set, then the parser can emit
: .method as $_.method, instead of $?IMPLICIT_INVOCANT.method.
The parser always emits .method as $_.method under any dialect, or
fails. What has changed is whether $_ sometimes means the invocant.
But the compiler needs to trigger ambiguity resolution -- i.e. check
for $?SELF agreement with $_ -- when it sees $?IMPLICIT_INVOCANT.
No need to do that if it sees $_.method. So they need to be different.
In any event, SMD methods always have a first argument, so you're never
in doubt at that point. And since .bar always means $_.bar, I don't
think you really have a problem here that's any harder than you already
had with $_.
The problem here is for the compiler to detect whether $_ agrees
with $?SELF, when it sees $?IMPLICIT_INVOCANT. If they agree,
$?IMPLICIT_INVOCANT gets replaced by $_; otherwise it is an error.
Consider this construct:
method foo {
$_ := $something_else if rand(2)1;
.bar;
}
That's one case where it's not possible to detect at compile time,
so it needs to silently let .bar go thru as $_.bar.
: Clearly we need a way to statically determine statement:given
: and statement:for will always assign at least one argument to
: its block argument. Without that, the compile-time analysis mandated by
: Larry is infeasible.
I think you can assume that given and for always bind at least one
argument. In particular, a for that binds 0 arguments will never
progress, plus you can recognize it:
But what in given and for signify that? I do not want to special
case based on function names, and statement:given may be rebound
to something else. How does that something else signify that it will
at least bind at least one argument to its code argument? Via the
signature of the code argument, i.e. the Any in codeAny?
sub statement:given (Any $topic, codeAny) { ... }
If so, what is the signature of for? I can't seem to write it down.
: Then, we need to figure out the structure for the magic flag set by
: self.pm on behalf of its caller. We are not using $^H anymore, so
: there needs to be a way to pass lexical settings to the caller.
Perhaps hints should just be considered lexically scoped $? variables.
You export them lexically just the same way you export any other lexically
scoped things, however that is.
How will you handle:
use Foo :my$x;
Seems like this is just a kind of
use Foo :my$?MYHINT
thingy, only perhaps you're just setting $?MYHINT rather than aliasing
it back into a Foo variable.
Yes, that's the main difference. How does the :my form of export work
in the exporter's end?
sub foo is exportmy { ... }
Will that work?
: Does this seem sane? The static detection of $_ is the showstopper
: currently, and Pugs will need to separate the compiler with PIL evaluator
: to implement the pragma.pm above.
I suspect you're making it complicateder than it needs to be, but
perhaps I don't understand the problem fully. Of course, the two are
not mutually exclusive...
Indeed I suspect both are true. :)
Thanks,
/Autrijus/
pgpUx78e7n7vf.pgp
Description: PGP signature
Re: method calls on $self
On Fri, Jul 08, 2005 at 08:50:35AM -0500, Jonathan Scott Duff wrote: On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote: And what will be the default syntax to call a method on self? If everyone has completly other preferences about this, for example this horrible ./method() syntax, which completly wont fit into the language, What a way to win friends! Some of us find ./method() to fit just fine into the language and into use. If telling my opinion is preventing us to become friends, i'm sorry for that. I heard some people to complain about the ./method() syntax too. Does the default syntax really matter that much? For your own code, use self ; is a small one-time cost to pay to get the syntax/semantics you want. Well, one-time cost per source file, but I can easily see that someone would build the scaffolding to let that be a one-time cost per site. (e.g. having a site-wide policy for perl6 has been mentioned before) Maybe per .-file in the home-directory, like .vimrc ... The only place I can see a problem is when reading other people's code, but then I expect that the hue and cry would be such that *someone* would write a tool to make it easy to transmogrify other perl6 dialects into the one they particularly like to use. And given how well perl6 will grok perl6, such a tool shouldn't be too difficult to write. Java-people also invent new tools to ease the pain of writing java-code. But Perl6 isn't as static as Java (of course) and will mutate into a custom language for any dedicated Perl6 programmer. It will be hard/easy to read someones elses Perl6 code regardless of the self-method() syntax. whose favorite will be the default? None at all? An explicit call, like $?SELF.method () ? Were I $Larry, that's what I'd do if people kept bringing it up and carping about the syntax that works--decide there's no default and you *always* have to be explicit in one way or another. Boy am I glad I'm not $Larry ;-) I would be completly fine with $?SELF.method () as default. Will we end in something like use my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_perl6_anymore; If that's your desire, perl ain't stopping you :-) I wanted to express my fear that perl6 might is pushing me to do that or others to do that. Robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
Re: method calls on $self
On Fri, Jul 08, 2005 at 08:50:35AM -0500, Jonathan Scott Duff wrote: On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote: And what will be the default syntax to call a method on self? If everyone has completly other preferences about this, for example this horrible ./method() syntax, which completly wont fit into the language, What a way to win friends! Some of us find ./method() to fit just fine into the language and into use. If telling my opinion is preventing us to become friends, i'm sorry for that. I heard some people to complain about the ./method() syntax too. Does the default syntax really matter that much? For your own code, use self ; is a small one-time cost to pay to get the syntax/semantics you want. Well, one-time cost per source file, but I can easily see that someone would build the scaffolding to let that be a one-time cost per site. (e.g. having a site-wide policy for perl6 has been mentioned before) Maybe per .-file in the home-directory, like .vimrc ... But i don't think that pushing everyone into his own language is the purpose of designing a new one. Also, i would be VERY curious how that 'self' module looks like. Is there already a spec that describes how to change the parser on the fly in such a module? And how many people, who dislike the ./-syntax will be actually able to write such a module? Or a module that works around another syntax design quirk in perl6? If the majority really wants ./, okay, i am fine with it. My own opinion is, that ./ doesn't fit into the language very much, at least not with a 'but it looks like shell programming'-argument. Perl6 isn't shell programming, and ./ has a completly different meaning (at least for me, and others i heard about this issue) in perl. The only place I can see a problem is when reading other people's code, but then I expect that the hue and cry would be such that *someone* would write a tool to make it easy to transmogrify other perl6 dialects into the one they particularly like to use. And given how well perl6 will grok perl6, such a tool shouldn't be too difficult to write. Java-people also invent new tools to ease the pain of writing java-code. But Perl6 isn't as static as Java (of course) and will mutate into a custom language for any dedicated Perl6 programmer. It will be hard/easy to read someones elses Perl6 code regardless of the self-method() syntax. I don't think that this kind of syntax-translation is so very easy... and what about a perl6 program in a cvs. You probably want to change the code you read... whose favorite will be the default? None at all? An explicit call, like $?SELF.method () ? Were I $Larry, that's what I'd do if people kept bringing it up and carping about the syntax that works--decide there's no default and you *always* have to be explicit in one way or another. Boy am I glad I'm not $Larry ;-) I would be completly fine with $?SELF.method () as default. Will we end in something like use my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_perl6_anymore; If that's your desire, perl ain't stopping you :-) I wanted to express my fear that perl6 might push me and others to write their own language plugin to work around suboptimal design in perl6. Robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
Re: method calls on $self
On Fri, Jul 08, 2005 at 10:07:24AM -0400, Stevan Little wrote:
On Jul 8, 2005, at 2:10 AM, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
syntax, which completly wont fit into the language, whose
favorite will be the default?
None at all?
An explicit call, like $?SELF.method () ?
I have never understood what is wrong with this:
method foo ($self: $bar) {
$self.baz()
}
Thats a fine option to have.
But therecomes another question to my mind:
what do i get with writing 'method' instead of
'sub'? is it just for seperating subroutines and methods optically
or is there a deeper reason?
Then you can easily so whatever you like:
## for our Java inclined friends
method foo ($this: $bar) {
$this.baz()
}
or C++
Why does it have to be some sugared syntax when you can just simple
name it in the parameter list?
Yes, but there seem to be quite some people who want
a 'cool' syntax for it. (ie. ./method ()).
No syntax at all, like in C++ just method() would
be the shortest. But larry says no, and everyone seems to
agree.
robin
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
Robin Redeker
Re: method calls on $self
On Fri, Jul 08, 2005 at 08:28:34PM +0200, Robin Redeker wrote:
: On Fri, Jul 08, 2005 at 10:07:24AM -0400, Stevan Little wrote:
: I have never understood what is wrong with this:
:
: method foo ($self: $bar) {
: $self.baz()
: }
:
: Thats a fine option to have.
: But therecomes another question to my mind:
: what do i get with writing 'method' instead of
: 'sub'? is it just for seperating subroutines and methods optically
: or is there a deeper reason?
Several deeper reasons. Though I quibble at characterizing the optical
reason as un-deeper when it might in fact be the deepest reason of all,
or at least closely related to very deep psychological reasons.
Off the top of my head:
Subs are never inherited.
Subs are not candidates for indirect object method calls.
Perl will only call sub new when called as a subroutine.
Subs create list operators, while methods don't.
Method calls are allowed to be argumentless.
Methods have access to instance variables.
Mutating/nonmutating methods can be generated from each other.
Explicit method declaration allows implicit invocant declaration.
Distinguishing multi method from multi sub allows different strategies.
: Why does it have to be some sugared syntax when you can just simple
: name it in the parameter list?
:
: Yes, but there seem to be quite some people who want
: a 'cool' syntax for it. (ie. ./method ()).
I wasn't thinking 'cool', I was thinking 'visually distinctive and
mnemonic'. I actually think o. is cooler.
: No syntax at all, like in C++ just method() would
: be the shortest. But larry says no, and everyone seems to
: agree.
Just to quibble again, I didn't just say 'no'. I also said,
use self ;
And no, everyone doesn't seem to agree. :-)
Larry
Re: method calls on $self
On Fri, Jul 08, 2005 at 05:43:01PM +0200, Robin Redeker wrote: : Maybe per .-file in the home-directory, like .vimrc ... Only if pulled in with a use. I don't want to see Perl programs implicitly starting in a variant language. Dialects must be declared. Otherwise you're in a situation like having a URI that starts at an unknown root. Have you ever noticed how frustrating it can be to sit down at someone else's vim sessions and discovering there are all sorts of implicit keyboard remappings you don't know about? At least with a language we have the possibility of declaring up front for anyone to see which variant of the language we're using. : The only place I can see a problem is when reading other people's code, : but then I expect that the hue and cry would be such that *someone* : would write a tool to make it easy to transmogrify other perl6 dialects : into the one they particularly like to use. And given how well perl6 : will grok perl6, such a tool shouldn't be too difficult to write. : : Java-people also invent new tools to ease the pain of writing java-code. : But Perl6 isn't as static as Java (of course) and will mutate into : a custom language for any dedicated Perl6 programmer. : It will be hard/easy to read someones elses Perl6 code regardless of the : self-method() syntax. That's why it's important not to allow implicit redeclarations of syntax. : whose favorite will be the default? None at all? An explicit call, : like $?SELF.method () ? : : Were I $Larry, that's what I'd do if people kept bringing it up and : carping about the syntax that works--decide there's no default and you : *always* have to be explicit in one way or another. : : Boy am I glad I'm not $Larry ;-) : : I would be completly fine with $?SELF.method () as default. That works by default. ;-) : Will we end in something like : : use : my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_perl6_anymore; : : If that's your desire, perl ain't stopping you :-) : : I wanted to express my fear that perl6 might is pushing me : to do that or others to do that. As long as that big use declaration is there at the top, we're at least forewarned. But it is my silly hope that Standard Perl 6 will be easy enough that people will be too Lazy to define their own major variants most of the time. Plus I'm hoping there will be some cultural pressure on gratuitous variants. (Though obviously if we provide a self pragma, we're encouraging a particular set of variants as part of the standard language.) Larry
Re: method calls on $self
On Thu, Jul 07, 2005 at 08:12:17PM -0700, Larry Wall wrote: The basic problem is that I always hated looking at C++ and not knowing whether I was looking at a function or a method, so I'm not going to make standard Perl work like that. On the other hand, there's always use self ; to go with everyone else's preferences: [... other use self examples ...] Did I leave anyone out? Larry And what will be the default syntax to call a method on self? If everyone has completly other preferences about this, for example this horrible ./method() syntax, which completly wont fit into the language, whose favorite will be the default? None at all? An explicit call, like $?SELF.method () ? Will we end in something like use my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_perl6_anymore; ? thanks, Robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
Re: method calls on $self
On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote: And what will be the default syntax to call a method on self? If everyone has completly other preferences about this, for example this horrible ./method() syntax, which completly wont fit into the language, What a way to win friends! Some of us find ./method() to fit just fine into the language and into use. Does the default syntax really matter that much? For your own code, use self ; is a small one-time cost to pay to get the syntax/semantics you want. Well, one-time cost per source file, but I can easily see that someone would build the scaffolding to let that be a one-time cost per site. (e.g. having a site-wide policy for perl6 has been mentioned before) The only place I can see a problem is when reading other people's code, but then I expect that the hue and cry would be such that *someone* would write a tool to make it easy to transmogrify other perl6 dialects into the one they particularly like to use. And given how well perl6 will grok perl6, such a tool shouldn't be too difficult to write. whose favorite will be the default? None at all? An explicit call, like $?SELF.method () ? Were I $Larry, that's what I'd do if people kept bringing it up and carping about the syntax that works--decide there's no default and you *always* have to be explicit in one way or another. Boy am I glad I'm not $Larry ;-) Will we end in something like use my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_perl6_anymore; If that's your desire, perl ain't stopping you :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: method calls on $self
On Jul 8, 2005, at 2:10 AM, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
syntax, which completly wont fit into the language, whose
favorite will be the default?
None at all?
An explicit call, like $?SELF.method () ?
I have never understood what is wrong with this:
method foo ($self: $bar) {
$self.baz()
}
Then you can easily so whatever you like:
## for our Java inclined friends
method foo ($this: $bar) {
$this.baz()
}
method foo
($my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_pe
rl6_anymore: $bar) {
$my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_per
l6_anymore.baz()
}
method foo ($o: $bar) {
$o.baz()
}
Why does it have to be some sugared syntax when you can just simple
name it in the parameter list?
Stevan
Will we end in something like
use
my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_per
l6_anymore;
?
thanks,
Robin
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
Robin Redeker
Re: method calls on $self
On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote: Hi, i just wanted to ask what was about the method calling syntax on $self, and why does method () not work for calling a method on $self? (like in C++) Because perl can't distinguish between the method foo() and the subroutine foo(). Or are you proposing that methods be added to the search space for name resolution? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: method calls on $self
On Thu, Jul 07, 2005 at 04:08:17PM -0500, Jonathan Scott Duff wrote: On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote: Hi, i just wanted to ask what was about the method calling syntax on $self, and why does method () not work for calling a method on $self? (like in C++) Because perl can't distinguish between the method foo() and the subroutine foo(). Or are you proposing that methods be added to the search space for name resolution? Yes, why not? I don't see any conflicts for moving the methods into the search space for methods. Robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
Re: method calls on $self
On 7/8/05, Robin Redeker [EMAIL PROTECTED] wrote: Hi, i just wanted to ask what was about the method calling syntax on $self, and why does method () not work for calling a method on $self? (like in C++) IIRC, Larry wants to be able to distinguish method calls from sub calls, so that when you see 'foo()' inside a method, you know that it's NOT using $?SELF. If you want to call a method, either use an explicit self, or use './method'. (As a side note, putting space between the sub/method name and the call parentheses is now disallowed. If you must have the space, you need to use '.()'.) Stuart
Re: method calls on $self
The basic problem is that I always hated looking at C++ and not knowing whether I was looking at a function or a method, so I'm not going to make standard Perl work like that. On the other hand, there's always use self ; to go with everyone else's preferences: use self . use self ` use self · use self .. use self ^. use self i. use self o. use self ¤. use self me. use self self. use self this. Did I leave anyone out? Larry
Re: method calls on $self
LW == Larry Wall [EMAIL PROTECTED] writes: LW to go with everyone else's preferences: LW use self . LW use self ` LW use self · LW use self .. LW use self ^. LW use self i. LW use self o. LW use self ¤. LW use self me. LW use self self. LW use self this. LW Did I leave anyone out? use self that. use self over_there. use self where_am_i. use self dis. use self dat. use self you. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: ./method defunct
On Mon, Jun 20, 2005 at 07:34:57PM -0400, Kurt wrote: On 6/18/05, Juerd wrote: Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I personally find ./method prettier and easier to type than any of the alternatives. I don't like it because I think method calls should look like method calls, and the slash separating the dot and name makes it look like something else entirely. On 6/19/05, Juerd wrote: David Storrs skribis 2005-06-19 13:45 (-0400): All that said, I still agree with John... './' does not look like method call syntax to me. That's good, because it's different from all other method syntax anyway, because it does not have any left hand side -- not even implied. I don't think it's good. A method call should look like a method call. What are the salient characteristics of looks like a method call? Is it no intervening characters between the . and the name of the method? Frankly, I don't understand the objection to using a keyword for $?SELF, such as `self`. Um ... isn't $?SELF a keyword? :-) Most other object-oriented languages use such a keyword, if not exactly the same one, so it will be a familiar concept. Certainly more readily understood for a newcomer than `./method`. I think the difference in how readily understood it is will be infinitesimally small. What's confusing about ./method is shorthand for $?SELF.method? As a bonus, `self` is easily searchable within the documentation, whereas `./` is not. I'll grant you that. But, as punctuation rich as perl is, we should provide a tool (p6doc?) to help with the searching and encourage people to use it. I missed responding to the thread the last time this subject came up, but the more I see this syntax the less I like it, so I wanted to add another voice to the dissention. However, if it remains official, I expect I'll simply be naming my invocants, as chromatic has suggested. I expect that soon after perl6 is released (heck, maybe before it's released) we'll get tools that will translate perl6 to perl6 while performing some syntactic manipulation. For instance, it could explicitize code (replacing ./method with $?SELf.method and .foo with $_.foo and so on) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: ./method defunct
What does this have to do with perl6-internals? F-up to p6l. Matthew Zimmerman skribis 2005-06-21 11:27 (-0400): $self-_fraction * $self-concentration + $s2-_fraction * $s2-concentration You can still write it like that, if you declare a name ($self) for the invocant. Added to Perl is a shortcut, not a replacement. ./:fraction * ./concentration + $s2.:fraction * $s2.concentration That looks silly indeed, and is a good reason for not using ./foo HERE. It's not a good reason to not have ./foo at all. and it gives me the willies. Then don't use it. You don't have to use it. If I have a complicated mathematical expression If you have anything that is complicated, a verbose version should always be considered, if only to avoid getting lost in punctuation. This is not specific to ./foo in any way. with method calls in it (which happens a lot for me), the '/' part of './' in particular gives me lots of visual problems. It is visually much more suited for action than functional use: ./foo($bar, $baz); # beautiful print 5 + ./foo($bar); # ugly at the top of my code if I have to, but I want to make one last gasp at getting $Larry / @Larry to reconsider this. I find o. absolutily horrifying. But then, that's apparently how you think of ./, so we have to trust Larry's decision on this. I don't think further discussing this is really fruitful, as it has already been discussed more than is good for us. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
Jonathan Scott Duff skribis 2005-06-21 10:00 (-0500): I expect that soon after perl6 is released (heck, maybe before it's released) we'll get tools that will translate perl6 to perl6 while performing some syntactic manipulation. For instance, it could explicitize code (replacing ./method with $?SELf.method and .foo with $_.foo and so on) Deparse. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
Juerd wrote: What does this have to do with perl6-internals? F-up to p6l. Sorry! Typing faster than my brain is working. Resent to the right list. If I have a complicated mathematical expression If you have anything that is complicated, a verbose version should always be considered, if only to avoid getting lost in punctuation. This is not specific to ./foo in any way. If I'm calling a method on $?SELF five times in a statement and you're only calling one once, wouldn't such an operator be more important to me than to you? I'm not arguing that having a short way to call a method on the current invocant-- be it operator or keyword-- is a bad thing. It's a great feature, and why I'm delurking to comment on this. If 'o.' really doesn't work, it doesn't work. We could pick a different operator. I'm just saying that the particular choice of './' doesn't work for me (and evidently a number of other people). It is visually much more suited for action than functional use: ./foo($bar, $baz); # beautiful print 5 + ./foo($bar); # ugly Right here, in my mind, is an argument against it. I'd end up using the operator in some places and not others, because in some contexts it'd be ugly and others beautiful. Thus further reducing the visual consistency of the code. I haven't yet given up on the idea that there's a shortened operator that would be more universally readable. at the top of my code if I have to, but I want to make one last gasp at getting $Larry / @Larry to reconsider this. I find o. absolutily horrifying. But then, that's apparently how you think of ./, so we have to trust Larry's decision on this. I don't think further discussing this is really fruitful, as it has already been discussed more than is good for us. Fair point. I mean no offense, nor do I wish to beat a dead horse. I just want to make sure it's dead, instead of merely resting. -- Matt Matthew Zimmerman Interdisciplinary Biophysics, University of Virginia http://www.people.virginia.edu/~mdz4c/
Re: ./method defunct
[Sorry, sent this to the wrong list by mistake.]
Matthew Zimmerman wrote:
Juerd wrote:
Kurt skribis 2005-06-20 19:46 (-0400):
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Certainly.
However, there has proven to be much demand for something like ./method,
and in such cases, having it by default is probably the best thing.
I personally don't think it's either necessary or too much. I care about
.method using $_, and many other people care about having short syntax
for self.method too. ./method was something that would work for me, so I
shared that idea, and it was generally accepted.
Apart from the personal joy of seeing something I invented become part
of the official language, I don't really care if ./method is eventually
part of Perl 6 or not. I have always named my invocants, and don't mind
continue to do so. On the other hand, if there is a shorthand, I will
use it, because regardless of whether you think it's pretty or ugly, and
regardless of whether you think it looks enough like a method call,
having a short two character operator for this is in fact very
convenient.
Could we revisit the idea of using a shorter keyword for $?SELF, like
'o'? I know that $Larry said the idea was probably not going to work:
http://tinyurl.com/7baz6
but I'm curious if the reasoning that killed it then still holds now,
now that './' has emerged as a replacement.
Count me among the './' dissenters, too. The virtual explosion of new
operators in Perl 6 has not concerned me too much, as I don't envision
myself using many of them, but the operation that './' does is something
I do very frequently. I'm just imaging a lot of my Perl 5 code like:
if ( $self-unit_id == $s2-unit_id ) {
$self-add_component(
$self-_fraction * $self-concentration +
$s2-_fraction * $s2-concentration
);
$self-update;
}
replaced with:
if ( $.unit_id = $s2.unit_id ) {
./add_component(
./:fraction * ./concentration +
$s2.:fraction * $s2.concentration
);
./update;
}
and it gives me the willies. If I have a complicated mathematical
expression with method calls in it (which happens a lot for me), the '/'
part of './' in particular gives me lots of visual problems.
I'll put
macro o () { '$?SELF' }
at the top of my code if I have to, but I want to make one last gasp at
getting $Larry / @Larry to reconsider this.
--
Matt
Matthew Zimmerman
Interdisciplinary Biophysics, University of Virginia
http://www.people.virginia.edu/~mdz4c/
Re: ./method defunct
On 6/18/05, Juerd wrote: Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I personally find ./method prettier and easier to type than any of the alternatives. I don't like it because I think method calls should look like method calls, and the slash separating the dot and name makes it look like something else entirely. On 6/19/05, Juerd wrote: David Storrs skribis 2005-06-19 13:45 (-0400): All that said, I still agree with John... './' does not look like method call syntax to me. That's good, because it's different from all other method syntax anyway, because it does not have any left hand side -- not even implied. I don't think it's good. A method call should look like a method call. Frankly, I don't understand the objection to using a keyword for $?SELF, such as `self`. Most other object-oriented languages use such a keyword, if not exactly the same one, so it will be a familiar concept. Certainly more readily understood for a newcomer than `./method`. As a bonus, `self` is easily searchable within the documentation, whereas `./` is not. The argument that this keyword cannot then be defined by user code is weak, as it would be rather hostile to use `self` for any other meaning inside of a class. I presume it could be overridden anyway, as with the other core built-ins, so it is not even an eternal loss, should the need actually arise. I missed responding to the thread the last time this subject came up, but the more I see this syntax the less I like it, so I wanted to add another voice to the dissention. However, if it remains official, I expect I'll simply be naming my invocants, as chromatic has suggested. Kurt
Re: ./method defunct
Kurt skribis 2005-06-20 19:34 (-0400):
However, if it remains official, I expect I'll simply be naming my
invocants, as chromatic has suggested.
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Kurt
Re: ./method defunct
Kurt skribis 2005-06-20 19:46 (-0400):
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Certainly.
However, there has proven to be much demand for something like ./method,
and in such cases, having it by default is probably the best thing.
I personally don't think it's either necessary or too much. I care about
.method using $_, and many other people care about having short syntax
for self.method too. ./method was something that would work for me, so I
shared that idea, and it was generally accepted.
Apart from the personal joy of seeing something I invented become part
of the official language, I don't really care if ./method is eventually
part of Perl 6 or not. I have always named my invocants, and don't mind
continue to do so. On the other hand, if there is a shorthand, I will
use it, because regardless of whether you think it's pretty or ugly, and
regardless of whether you think it looks enough like a method call,
having a short two character operator for this is in fact very
convenient.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
John Siracusa wrote: On 6/18/05 8:28 PM, Juerd wrote: The unix shell and things resembling it will still be in use much fifteen years after today, Perl 5 will not. Ooo, a bold prediction :) Heh, it is indeed. And it means given the 16,000,000 lines of Perl in CPAN, we only have to keep the porting rate up at around a million lines of code a year. Adam K
Re: ./method defunct
On Jun 18, 2005, at 9:24 PM, Damian Conway wrote: chromatic wrote: I find it ugly enough that I plan to name my invocants explicitly. ...which should be construed as a *feature* of the current syntax. ;-) Damian In that case, why do we have this feature? Seriously. Are default invocants really such a good idea? At least, do they need to be there in 6.0.0? Do they need to be supported in the core engine, or could they be pushed out to a module? I guess that as long as we're arguing the color, we might as well argue the location of the bikeshed. All that said, I still agree with John... './' does not look like method call syntax to me. But, whatever. I suppose I'll get used to this, along with all the other things that have given me the heebie- jeebies so far. :/ --Dks
Re: ./method defunct
David Storrs skribis 2005-06-19 13:45 (-0400): Seriously. Are default invocants really such a good idea? Yes, as long as the default is $_. ./method doesn't use a default invocant. It calls method on the current invocant, which happens to be available as $?SELF: that doesn't mean it defaults to $?SELF. The term default is inappropriate if there is no way to specify anything else: $object./method is still invalid syntax. All that said, I still agree with John... './' does not look like method call syntax to me. That's good, because it's different from all other method syntax anyway, because it does not have any left hand side -- not even implied. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
The reason we ended up at ./method was simply because it was the best suggestion anyone had. Compared to the previous suggestions it was way ahead. It's other advantage is that (except for on nordic keyboards) dot and slash are generally right next to each other, so the expense of using it is two chars and one fingering position, as they would likely be hit by fourth and fifth fingers (for touch typist style) and some other two fingers for the rest of us, and only 1 cm travel for hunt and peck. It has a very low RSI index :) (something I don't think we take into account enough as it is when we use the Huffman name to justify shortening something) So call it (2ch|2key|1pos|1cm) cost .::method on the other hand is 2 chars, 4 keystrokes, one of which must be held down between the two colons, is a strech for touch typists, requires you to get you hand completely away from the letters for the rest, and god help the hunt and peckers. Something like (3ch|4.5key|2pos|5cm) cost. And I dislike having a THIRD sigil even more than I dislike the second. Adam K I think $ is way more objectionable to the lily-white non-Perl heathens, but I don't really care about them either way. I'm just saying ./ screams file path to me, or maybe even typo-ed Java/C++ comment or something. Certainly not method invocation or implicit invocant. The .: thing, OTOH, totally works for me and I've always liked it. I'm just trying to stretch it to cover both public and private. Maybe there's something better than both.
Re: ./method defunct
On 6/18/05 12:23 AM, Adam Kennedy wrote: The reason we ended up at ./method was simply because it was the best suggestion anyone had. That's what I'm trying to remedy :) It's other advantage is that (except for on nordic keyboards) dot and slash are generally right next to each other, so the expense of using it is two chars and one fingering position, as they would likely be hit by fourth and fifth fingers (for touch typist style) and some other two fingers for the rest of us, and only 1 cm travel for hunt and peck. As I noted, . and : are also right next to each other. Yes, there's a modifier (shift) for one of them, but I didn't see anyone crying when .: was originally proposed, and .:: is just a double-tap on the 2nd key. IMO, the RSI index is basically a wash between .: and ./. The ugliness and appropriateness indexes, OTOH, heavily favor .: and .::, IMO. BTW, I'm still not sure which will be more common, private or public implicit-invocant method calls. I assigned .:: to private because it simply looks more internal to me. And I dislike having a THIRD sigil even more than I dislike the second. Objective-C has some spare characters if you're feeling adventurous :) [.method()] # ha, jk .-method() [EMAIL PROTECTED]() Hm, that last one actually isn't half bad, the mnemonic being call this 'at' the current object...or something. Again, maybe it's not feasible due to parsing constraints. How about resurrecting the spirit of the arrow? .method() That actually looks more private to me. Let's line 'em up again: PUBLIC PRIVATE -- -- ./method() .:method() [EMAIL PROTECTED]() .:method() .method() .:method() .:method() .method() .:method() .::method() I'm just trying to get some more suggestions out there on paper, because it seemed to me that the old thread jumped from ^ to ./ with less exploration than I'd like. -John
Re: ./method defunct
At 7:52 AM -0400 6/18/05, John Siracusa wrote: That actually looks more private to me. Let's line 'em up again: PUBLIC PRIVATE -- -- ./method() .:method() [EMAIL PROTECTED]() .:method() .method() .:method() .:method() .method() .:method() .::method() I'm just trying to get some more suggestions out there on paper, because it seemed to me that the old thread jumped from ^ to ./ with less exploration than I'd like. As I recall, it was decided for a broad scope that public and private item invocation syntax was exactly the same but with the consideration that all private items have a ':' as the first character in their otherwise alphanumeric names (the ':' looks like part of an operator but it isn't). That seems to be getting ignored in this discussion, and I *like* that ':' public vs private consistency, so here's an alteration to your table: PUBLIC PRIVATE -- -- ./method() ./:method() [EMAIL PROTECTED]() .@:method() .method() .:method() This looks way more consistent and predictable to me. -- Darren Duncan
Re: ./method defunct
Darren Duncan skribis 2005-06-18 11:40 (-0700): item invocation syntax was exactly the same but with the consideration that all private items have a ':' as the first character in their otherwise alphanumeric names (the ':' looks like part of an operator but it isn't). Except for attributes, which play a different game: the colon comes *instead* of the dot as the twigil, while the accessor method gets : in front of its name. If I recall correctly, the syntax is very misleading in that it is NOT part of the name. I don't like the inconsistency. PUBLIC PRIVATE -- -- ./method() ./:method() ./:method is what I originally suggested along with my suggestion of ./method itself. I strongly dislike that .:method would work on $?SELF and I also strongly dislike the contrived and false two-\W-characters-mean-invocant-otherwise-it's-$_ rule. (It'd be true (but would still feel artificial) if .+method would also use the invocant. Which I pray is not the case.) I do not want there to be any indication of there being two defaults and that there is a way to select the other default. ./ is an operator by itself and not the combination of . and /, and it cannot be used infix. There is only ever one default variable|object in syntax, and that is $_. I'd like the colon to be part of the name, like underscore is used in Perl 5: outside access is discouraged but entirely possible. I don't think ANY syntax should be special cased for a method, just because it's private. That doesn't mean there can't be a warning (warnings are not syntax), and in fact a warning is all there should IMO be. This means these public-private equivalency pairs exist: $foo.bar $foo.:bar .bar .:bar ./bar ./:bar $.bar $.:bar # I wouldn't mind if $:bar were an *abbreviation* .+bar .+bar ./+bar ./+:bar (People could introduce other prefixes (although the number of available characters is very limited) for other accessability indicators, like perhaps [EMAIL PROTECTED] to allow web access. [EMAIL PROTECTED]() .@:method() In Perl, @ has a VERY strong association with arrays, so except for specialised frameworks, I recommend against using it for other purposes. .method() .:method() I think has just enough purposes, and that it should be left alone now. gt = pair == pipe qw qw +, ~ shift -, - sub Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
On 6/18/05 2:40 PM, Darren Duncan wrote: As I recall, it was decided for a broad scope that public and private item invocation syntax was exactly the same but with the consideration that all private items have a ':' as the first character in their otherwise alphanumeric names (the ':' looks like part of an operator but it isn't). Doh! If that's the case, then your revised table is indeed the place to start. I'll throw one more on for good measure. PUBLIC PRIVATE -- -- ./method() ./:method() [EMAIL PROTECTED]() .@:method() .method() .:method() .-method() .-:method() I was also thinking about putting something before the . instead of after it. That actually makes more sense as a location for a syntax for an implicit invocant, since the invocant would come before the . too. Unfortunately, a that syntax is used for member variables and such, so the usual sigils are out ($ @ % ), and the rest start to look like unary operators on method calls implicitly made on $_ (e.g., -.method()) So we're back to the table above, I guess. I miss .::method(), but of the above choices I think I'd rank them this way, from best to worst. PUBLIC PRIVATE -- -- [EMAIL PROTECTED]() .@:method() # best .method() .:method() # . .-method() .-:method() # . ./method() ./:method() # worst It was a tough battle for last place, but in the end I think - even is a nicer placeholder for an implicit something. I just can't get over the path-y-ness of ./ (not to mention the division-y-ness) -John
Re: ./method defunct
John Siracusa skribis 2005-06-18 19:55 (-0400): ./method() ./:method() [EMAIL PROTECTED]() .@:method() .method() .:method() .-method() .-:method() [...] ./method() ./:method() # worst Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I personally find ./method prettier and easier to type than any of the alternatives. I was also thinking about putting something before the . instead of after it. That actually makes more sense as a location for a syntax for an implicit invocant, since the invocant would come before the . too. It's not implicit invocant. You're not selecting a second default (the first being $_). The slash does not represent $?SELF. And there is no such thing as $object./method. Instead, see ./ as a whole. I agree that the dot makes it look like .:, .+, .=, but anything without the dot is practically impossible because we're out of characters. ^ is the only single-character possibility. Many people have said to dislike ^method, some have said to like it. And if you're using two characters, ./ is a good one because it's easy to type, good looking and looks familiar (and can thus get a mnemonic, even if the metaphor is far fetched). Unfortunately, a that syntax is used for member variables and such, so the usual sigils are out ($ @ % ), and the rest start to look like unary operators on method calls implicitly made on $_ (e.g., -.method()) -.method should return -5 if .method returns 5. Minus in term position is already taken. Please refer to the available operator characters thread: we have only ^ we can reliably use without shuffling other things around or using whitespace. It was a tough battle for last place, but in the end I think - even is a nicer placeholder for an implicit something. I just can't get over the path-y-ness of ./ (not to mention the division-y-ness) The pathiness was on purpose. In fact, ./pugs inspired it and a metaphor between cwd and $?SELF plays for mnemonic. The divisioniness is something you'll just have to get over. Do you see any division in /\w+/? Or any addition in $foo +| $bar? Or any comparison in =, +, or ? Or any price in $var? Or any percentage in %hash? Or any conjunction in sub? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
On 6/18/05 7:54 PM, Juerd wrote: [EMAIL PROTECTED]() .@:method() In Perl, @ has a VERY strong association with arrays, so except for specialised frameworks, I recommend against using it for other purposes. The / character has very strong associations in nearly every programming language with division. In Perl it's also strongly associated with regexes, albeit in pairs. In Unix and URLs, it's associated with file paths. At least @ is vaguely associated with method calls in one existing programming language (Objective-C). .method() .:method() I think has just enough purposes, and that it should be left alone now. gt = pair == pipe qw qw +, ~ shift -, - sub I don't think there's any confusion between .method() and the other uses. In fact, I'd say there's less potential ambiguity about the in .method() than in some of other uses of the character. And that's what's important: ambiguity, not some arbitrary limit on the number of places that a character should be used. Also, in the context of Perl, 's historic usage in as the method caller thingie - in Perl 5 and its Perl 6 usage as the sub thingie - ties to method/function calls much more strongly than /. -John
Re: ./method defunct
John Siracusa skribis 2005-06-18 20:16 (-0400): On 6/18/05 7:54 PM, Juerd wrote: In Perl, @ has a VERY strong association with arrays, so except for specialised frameworks, I recommend against using it for other purposes. The / character has very strong associations in nearly every programming language with division. That is true. But in nearly every single US household and business, the dollar sign has to do with money. We create our own uses for existing characters. Sometimes this is based on something that we can recognise from inside or outside Perl, but almost never is something avoided because it has another meaning in another context. Perl would not be possible if we'd let ourselves be limited by this. In Perl it's also strongly associated with regexes, albeit in pairs. Regexes and other quotelike forms. qw/foo bar/ is very common use. $/ had nothing to do with regexes in Perl5 (in a way, it did have to do with division), but it will in Perl 6. Even though it's not in pairs. In Unix and URLs, it's associated with file paths. Yes. And . in a file path means current working directory. That's about as close to current working invocant as one can get :) At least @ is vaguely associated with method calls in one existing programming language (Objective-C). I don't know objective C. .method() .:method() I think has just enough purposes, and that it should be left alone now. gt = pair == pipe qw qw +, ~ shift -, - sub I don't think there's any confusion between .method() and the other uses. I think there is. There is little point in further arguing over this. Also, in the context of Perl, 's historic usage in as the method caller thingie - in Perl 5 and its Perl 6 usage as the sub thingie - ties to method/function calls much more strongly than /. - in Perl 6 not being related in any way (except spelling) to what - used to do in Perl 5 makes this highly irrelevant. The unix shell and things resembling it will still be in use much fifteen years after today, Perl 5 will not. Perl 6 is much about not letting history get in the way of good things. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
On 6/18/05 8:11 PM, Juerd wrote: John Siracusa skribis 2005-06-18 19:55 (-0400): ./method() ./:method() [EMAIL PROTECTED]() .@:method() .method() .:method() .-method() .-:method() [...] ./method() ./:method() # worst Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I personally find ./method prettier and easier to type than any of the alternatives. I think it's jarring. It definitely doesn't look like a method call to me. It looks out of place, like a typo of some kind. That was my honest initial reaction, as I posted earlier. I literally didn't even consider that it could be some sort of new syntax--and that's saying a lot considering I was reading p6l. I though GMail had mangled the text while trying to interpret quoting or something. It was a tough battle for last place, but in the end I think - even is a nicer placeholder for an implicit something. I just can't get over the path-y-ness of ./ (not to mention the division-y-ness) The pathiness was on purpose. In fact, ./pugs inspired it and a metaphor between cwd and $?SELF plays for mnemonic. I understand that, but I don't think it's a very applicable analogy. First, I think it's a long bridge from the file/path world to method calls. Second, even ignoring that, ./ in file/path context is a composition of two well-defined primitives, rather than the single unit proposed for Perl 6, the call this on $?SELF operator. (That could also be why I was breaking ./ down into . and / earlier, proposing alternatives for the / part alone.) The divisioniness is something you'll just have to get over. Do you see any division in /\w+/? No, because it's in pairs there (and because of ~12 years of perl 4-5 :) Or any addition in $foo +| $bar? Or any comparison in =, +, or ? Or any price in $var? Or any percentage in %hash? Or any conjunction in sub? I do see a bit of addition in +|. The constructs mostly look arrow-y to me, which is usually the intention (again, except in pairs where it looks bracket-y). Price in $var, well, years of shell combine there with years of perl (not to mention BASIC or whatever :) % and mostly ride on the perl 4-5 wave mentioned above. Anyway, I'm just giving my opinion. At least three other people agree with me, although we do seem to be in the minority so far. I'm just hoping there's an alternative that everyone will like better :) -John
Re: ./method defunct
On 6/18/05 8:28 PM, Juerd wrote: The unix shell and things resembling it will still be in use much fifteen years after today, Perl 5 will not. Ooo, a bold prediction :) -John
Re: ./method defunct
John Siracusa skribis 2005-06-18 20:35 (-0400): On 6/18/05 8:28 PM, Juerd wrote: The unix shell and things resembling it will still be in use much fifteen years after today, Perl 5 will not. Ooo, a bold prediction :) Do you really think so? I think that there is no way that Perl 5 can survive another 15 years. It used to be the best tool for almost everything, but for some purposes there are already better tools. Perl 5 had a long life for a dynamic language, but it's fading quickly. Web monkeys choose PHP now (they wouldn't have if our interpreters were light weight and mod_perl could be more like mod_php), larger systems are more and more written in Ruby and Python, and with PCRE, using regexes for basic string manipulation got easy in dozens of languages. The only things that really keeps Perl 5 alive (sort of) are CPAN and the community. The community is a fragile thing, and CPAN is more and more known as that uncontrolled place where any newbie can upload their templating engine and DBI wrapper. While unixish shells probably won't evolve much further. Microsoft is trying now, but their approach isn't needed in sh-land, because we've used those techniques for ages. The syntax is somewhat awkward, but if that's the only thing, you take it for granted because that keeps things compatible with existing code. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
John Siracusa skribis 2005-06-18 20:33 (-0400): I literally didn't even consider that it could be some sort of new syntax--and that's saying a lot considering I was reading p6l. You missed a 33 message thread that was referred to many times. Such things happen, I am surprised by new inventions all the time too because I don't read everything that flashes by. Still, if you hadn't missed the thread in question, or if you had read documentation about this, then you wouldn't have been surprised. I'm sure someone who hasn't been paying attention finds [+] or + or even foo bar extremely weird, but that does not influence the design. The simple fact that someone who doesn't read the manual is lost entirely, remains with Perl 6. The divisioniness is something you'll just have to get over. Do you see any division in /\w+/? No, because it's in pairs there (and because of ~12 years of perl 4-5 :) I think the remark in parens is extremely important. Perl is an operator based language. Thinks WILL looks weird if you don't know the language. But it just takes some time. I'm just hoping there's an alternative that everyone will like better As long as I'm part of everyone, that won't happen. I've listed numerous possibilities for myself, and found none that I liked better than ./method. I don't think you can come up with a pretty and easy-to-type and unambiguous ASCII based operator that I haven't considered yet. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
On Sun, 2005-06-19 at 02:11 +0200, Juerd wrote: Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I find it ugly enough that I plan to name my invocants explicitly. -- c
Re: ./method defunct
On 6/18/05 8:55 PM, Juerd wrote: I'm just hoping there's an alternative that everyone will like better As long as I'm part of everyone, that won't happen. I've listed numerous possibilities for myself, and found none that I liked better than ./method. I don't think you can come up with a pretty and easy-to-type and unambiguous ASCII based operator that I haven't considered yet. I think I'd be just as happy if we found an alternative that everyone but Juerd liked better (just as I'm sure you'd be okay if everyone but me liked ./ the best ;) Anyway, this isn't really a democracy. Who knows what evil syntax lurks in the mind of Larry... (well, other than The Shadow, natch :) -John
Re: ./method defunct
chromatic wrote: I find it ugly enough that I plan to name my invocants explicitly. ...which should be construed as a *feature* of the current syntax. ;-) Damian
Re: ./method defunct
At 1:54 AM +0200 6/19/05, Juerd wrote:
Except for attributes, which play a different game: the colon comes
*instead* of the dot as the twigil, while the accessor method gets : in
front of its name. If I recall correctly, the syntax is very misleading
in that it is NOT part of the name.
I would argue that the same rule applies to attributes and methods
alike; privates of both have ':' as part of their name, and *every*
attribute or method reference, public or private, has a '.'. No
instead here.
So if you just factor out the ':' as being part of a private thing's
name, then all other discussions for syntax can treat public and
private the same way.
This goes for both explicit invocant forms like $obj.attr or
$obj.meth and implicit forms like $.attr or $.meth, where in all
cases 'attr' or 'meth' may or may not contain a leading ':', but it
doesn't matter for the main discussion, except that ':' can't be used
in the trailing edge of the operator.
Its much more consistent that way.
$.bar $.:bar # I wouldn't mind if $:bar were an *abbreviation*
I agree and would accept $:bar *if* it were officially an
abbreviation, as you suggest, just like one can omit the '.' on
things like $foo.[0].{'bar'}; however, the full/longer form should
always be valid syntax.
-- Darren Duncan
Re: ./method defunct
Oops, part of Diamian's quoted text got trimmed accidentally in my last post. It should have looked like this: On 6/17/05 10:42 PM, John Siracusa wrote: [...] I'm not, however, buying Damian's argument here: On 2005-05-15 20:33:19, [EMAIL PROTECTED] (Damian Conway) said: This missing design rationale here is that the colon acts as part of the unary operator: ./unary public-method-call-on-invocant .:unary private-method-call-on-invocant So the rule is: One-character operator -- call on $_ Two-character operator -- call on $?SELF It strikes me as more of a rationalization than a rationale--picking out patterns after the fact, because that's what our brains like to do. [...] -John
Re: ./method defunct
On Jun 17, 2005, at 10:42 PM, John Siracusa wrote: But the truth is that / really does look file-path-y to me, and just plain old ugly. I think at least two other people had similar reactions (Martin Kuehl and Carl Franks). David Storrs, reporting to show solidarity, sir(acusa)! Maybe .:: has even more detractors, I dunno. All I know is that I dislike ./ and I'm trying to come up with an alternative. What say you all? Too many dots in .::? Surely ./ isn't as good as it gets... I'm not fond of .:: because I don't think it's sufficiently visually distinct from .:. I don't have a better suggestion...but that's mostly because I dislike this entire concept of secondary sigils. I already get to have the Perl is line noise! conversation _way_ too often...I don't feel that we need to give the trolls more ammunition. For that matter, I'm a Perl zealot and /I/ think they're ugly and obfuscatory. For what it's all worth, I suppose. --Dks
Re: ./method defunct
On 6/17/05 10:56 PM, David Storrs wrote:
I'm not fond of .:: because I don't think it's sufficiently visually
distinct from .:.
Hm, let's look at it:
method total(...)
{
.::sanity_check();
return .:value_one() + .:value_two();
}
Maybe lined up?
.::internal_value();
.:public_value();
I don't mind it, dots and all. I also think the .:: is quickly identifiable
as thicker than .: even at a glance. YMMV.
I don't have a better suggestion...but that's mostly because I
dislike this entire concept of secondary sigils. I already get to
have the Perl is line noise! conversation _way_ too often...I don't
feel that we need to give the trolls more ammunition.
I think $ is way more objectionable to the lily-white non-Perl heathens, but
I don't really care about them either way. I'm just saying ./ screams file
path to me, or maybe even typo-ed Java/C++ comment or something.
Certainly not method invocation or implicit invocant. The .: thing,
OTOH, totally works for me and I've always liked it. I'm just trying to
stretch it to cover both public and private. Maybe there's something better
than both.
(You know, if I had a nickel for every minute I've spent staring at my
keyboard's key caps while reading the p6 lists over the years...)
-John
Re: ./method
On 5/15/05, Juerd [EMAIL PROTECTED] wrote: A few days ago, when typing ./pugs,... You can guess the rest :) I suggest ./method to mean $?SELF.method, and ../method to mean $?SELF.SUPER::method, or however that's normally written. This syntax doesn't clash with anything, doesn't introduce whitespace asymmetry and doesn't require anything other than ASCII. If you go back to what inspired it, the mnemonic becomes clear: unix filesystems. However, it's far fetched and none of the people I've asked think it's a good one. Still, it works for me and may even work in textbooks. The best thing about this new proposal is that everyone so far agrees that it's feasible, easy to write and not ugly. I have tried, but I can't make myself like it. The syntax surely is feasible, easy to write and not ugly, but it makes me think about objects in terms of pathnames with . meaning $?SELF and / where other languages use the dot, except I can't use it for anything but a method call on the implicit receiver. It also makes me want to propose zsh-extended-glob-compatibility syntax for objects so I can have method/attribute slices, and then I end up curled up in a corner, scared and shaking. But maybe I should just get used to that. :-) Juerd Martin
Re: ./method
On 5/19/05, Martin Kuehl [EMAIL PROTECTED] wrote: I have tried, but I can't make myself like it. aolI'm afraid I have to agree./aol When I saw it used in code after this discussion (I think it must have been somewhere in pugs t/ or ext/) my reaction was yuck. (for what it's worth) Carl
Re: ^method ?
HaloO Juerd, you wrote: (This illustrates my feeling about @foo[] being the same as @foo. It feels inconsistent with foo() not being foo.) I have the same feeling. But I would like @foo[] to mean something else than plain @foo which should be---hmm, how shall I put that---a underefenced reference to whatever hides behind the ref|variable|name. The [] then does the deref like () derefs foo. Regards, -- TSa (Thomas Sandlaß)
Re: ^method ? (Is $_ still aliasing $?SELF?)
Damian Conway wrote:
Now, personally, I would like to see a short-cut for *both* types of
method call,...
Looks like this syntax is now .method and ./method plus the private
counterpart .:method.
If I have .foo() as $_.foo(), then I can get unary method call on
invocant very easily, even if methods don't topicalize their invocant.
method bar ($_:) {
.foo();
}
Ahh, does this mean that the auto-aliasing is ditched?
I personally regard $_ as a bit too volatile and if it
is a rw binding it's outright dangerous to not have access
to $?SELF after some topicalizing statement! Or am I missing
something? I mean are all topicalizers properly temping $_?
How is that enforced in non-standard code?
BTW, is $_ more a global variable with lexical overriding or an
always passed implicit argument to blocks? E.g. all methods get
an implicit *%_ or was that for submethods only?
--
TSa (Thomas Sandlaß)
Re: ^method ?
On 15/05/05 22:48 +0100, Matthew Walton wrote: I don't think that is what Rob is saying at all. It wasn't aimed entirely at Rob. I have a bad habit on mailing lists of vaguely replying to the entire thread without remembering who said what and being too lazy to check. My read: .method($foo); always means: $_.method($foo); and $self.method($foo); always means $?SELF.method($foo); The former is consistent with the rest of Perl 6, and the latter is consistent with most of Perl 5 OO code in the wild. My only stance is that, given there is no clearly sexy solution, at least I can take `$self` home to meet my Mom. Perhaps. However, I'm uncomfortable with the idea of $self being automatically assigned, because so far Perl 6 seems to have managed to avoid automatically providing anything in what I've been thinking of as the 'normal' or 'user' namespace. $?SELF looks 'special'. Admittedly it might be nicer if it was $?self, because it still looks 'special'. It's the same kind of thing that makes me wonder why $a and $b in sort was ever considered a good idea. But then perhaps I'm just odd... choosing a name for the invocant yourself if you don't want $?SELF or $_ to be it (although they will be anyway of course) seems to me to be the height of programming sexiness. I like being able to name things myself. The ./method() thing proposed in another thread is pretty cool too, by the way, and largely renders this thread moot. So perhaps I should have replied to that...
Re: ./method
Damian Conway skribis 2005-05-16 10:33 (+1000):
This missing design rationale here is that the colon acts as part of the
unary operator:
./unary public-method-call-on-invocant
.:unary private-method-call-on-invocant
So the rule is:
One-character operator -- call on $_
Two-character operator -- call on $?SELF
I was very specific about ./ being prefix only. Aligning it with .: is
ugly, because .: can be used infix.
$object.method
$object.:method
given $object {
.method
.:method # !!
}
Either it should do the expected thing, default to $_, or one of .:'s
syntaxes must be made invalid. Don't try to convince me that prefix .:
is an entirely different operator, because it is spelled the same and
does the same thing (call a private method). The only thing that's
different is that its invocant is left out of the code, and when we then
use something that isn't there, we call that a default. And defaults are
always $_, never $?SELF. But that you know.
Anything that begins with a dot looks way too much like the lone dot to
subtly mean something else.
Either infix .: must go away, or prefix .: must operate on $_.
I think infix .: can go, because calling private methods should be
harder anyway. Make that $object.!!(:)method for all I care.
And I think method :name must be very differently spelled, because it
looks like : is part of the name, which makes me want consistency:
$o.private $.private .private ./private
$o.:private $.:private .:private ./:private
Even forcing whitespace between : and name would already solve this:
method : name. It's ugly though.
To be honest, the current fog around private methods, and my not liking
much of the way they work, is pushing me towards good old _private
instead, ignoring the whole wildly special cased colon method thingies.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: ^method ?
All~ I feel like people have lost track of one of the initial arguments for having C .method == $?SELF.method . Currently, all of $.foo @.foo %.foo and their ilk operate on the current invocant, $?SELF. This leads naturally toward .foo also refering to $?SELF. But as we all know the is optional on function calls... This symmetry and regularity seems like a powerful thing to me and I would not want to lose it... Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: ^method ?
On Mon, May 16, 2005 at 02:26:02PM -0400, Matt Fowles wrote: $.foo @.foo %.foo and their ilk operate on the current invocant, $?SELF. This leads naturally toward .foo also refering to $?SELF. But as we all know the is optional on function calls... I believe you are thinking in Perl 5. :) In Perl 6, foo is a reference to the function foo, and never a call. That makes it symmetric with the other $.foo notations. Matt -- wolverian signature.asc Description: Digital signature
Re: ^method ?
Hi,
wolverian wrote:
On Mon, May 16, 2005 at 02:26:02PM -0400, Matt Fowles wrote:
$.foo
@.foo
%.foo
and their ilk operate on the current invocant, $?SELF. This leads
naturally toward .foo also refering to $?SELF. But as we all know
the is optional on function calls...
I believe you are thinking in Perl 5. :) In Perl 6, foo is a
reference to the function foo, and never a call. That makes it
symmetric with the other $.foo notations.
yes, but with parens, it *is* a call:
sub foo(...) {...}
say foo(...); # Calls foo
say foo(...); # Calls foo
say foo; # CODE(0x) or somesuch
(FWIW, I agree with Matt, but Juerd's ./method is nice, too. And we
shouldn't forget that Perl 6's OO is *far* more than that method on
self thing. I favour .method meaning $?SELF.method, but this only a
very minor issue when comparing with roles, autogenerated accessors,
anonymous roles|classes, parameterized roles, etc. :))
--Ingo
--
Linux, the choice of a GNU | The next statement is not true. The
generation on a dual AMD | previous statement is true.
Athlon!|
Re: ^method ?
Ingo Blechschmidt skribis 2005-05-16 21:28 (+0200):
yes, but with parens, it *is* a call:
sub foo(...) {...}
say foo(...); # Calls foo
say foo(...); # Calls foo
say foo; # CODE(0x) or somesuch
Only because there's an implicit . there. This is like saying that an
array is an array element, but only if you use square brackets.
(This illustrates my feeling about @foo[] being the same as @foo. It
feels inconsistent with foo() not being foo.)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: ^method ?
Rod Adams skribis 2005-05-14 20:09 (-0500): o. O. this. self. me. Not special syntax, meaning you can no longer use these identifiers for your own class. Bad style to use single-letter identifiers, but we know what trouble $a and $b in Perl 5 cause, and the B:: namespace. I believe they could all be implemented as a global function that returns $CALLER::?SELF, or however you spell that. They can, but that does not free up the identifiers for user definition. I wonder how CALLER::'s $?SELF is written too :) ° (an idea I just had. would likely need a 7-bit option as well) Not on any of the keyboards that I regularly use, and the ascii-equivalent would be \w, which has the problems described above. Neither is ¥ (except in Japan, but I don't think that was a deciding factor), which has a 7-bit version that isn't even infix. However, it is in the extended ASCII table, same as « » ¥. so the 7-bit version could just be $?SELF, and act as an encouragement for people to get better editors. With the Windows US-International keyboard layout, it's AltGr-Shift-; Other systems should have standard ways to type it as well. Yen has an ascii equivalent that is \w, but that doesn't clash with identifiers because Y is an infix operator. Terms are not expected there. There is no extended or 8-bit ASCII. ASCII is 7 bits by definition and has 128 characters. The character set you're using is called iso-8859-1, also known as latin-1. I don't buy the encouragement to get better editors thing. Using digraphs in the editor is extremely poor huffmanization, even though the end result is short. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ^method ?
Rob Kinyon skribis 2005-05-14 21:12 (-0400): What's wrong with just defaulting to $self? Are you kidding, trolling or just completely ignorant of what has been discussed the past days? That's standard P5 OO, expected everywhere No, Perl 5 has no default for methods. Its - always needs an LHS. Or was your choice of words poor, and did you not mean to discuss the dot's *default*, but instead a standard way to write the current invocant? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ^method ?
On Sun, May 15, 2005 at 01:19:53PM +0200, Juerd wrote: Or was your choice of words poor, and did you not mean to discuss the dot's *default*, but instead a standard way to write the current invocant? I think what Rob suggested is that: method ($foo) means method ($self: $foo) by default, but you can still override it with the invocant name of your choice. Thanks, /Autrijus/ pgpicCyVKk9Ry.pgp Description: PGP signature
Re: ^method ?
Autrijus Tang skribis 2005-05-15 19:28 (+0800): On Sun, May 15, 2005 at 01:19:53PM +0200, Juerd wrote: Or was your choice of words poor, and did you not mean to discuss the dot's *default*, but instead a standard way to write the current invocant? I think what Rob suggested is that: method ($foo) means method ($self: $foo) Then I hereby apologise to Rob for my own poor choice of words. I don't like the idea of having a normal identifier ever used by default, except $_, which is already aliased to the invocant. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method
On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd wrote:
I suggest
./method
to mean $?SELF.method
Your opinions please! (I ask those who already responded off-list, to
repeat their opinion here)
I like it. Tentatively implemented as r3253 for people to experiment
with. The converted examples/games/wizard.p6 looks good; the relevant
snippet is paraphrased below:
class Person is Mortal {
has Weapon %.weapons;
...
method battle_choice (Monster $enemy) {
given prompt(Your choice?) {
when %.weapons {
./attack($enemy, $.weapons{$_});
}
}
...
}
}
Thanks,
/Autrijus/
pgpNNHVNEvjPo.pgp
Description: PGP signature
Re: ./method
On Sun, May 15, 2005 at 13:44:44 +0200, Juerd wrote: A few days ago, when typing ./pugs,... You can guess the rest :) I suggest ./method to mean $?SELF.method, and ../method Your opinions please! (I ask those who already responded off-list, to repeat their opinion here) Wonderful! -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me whallops greyface with a fnord: neeyah!!! pgpEXOgsYEirP.pgp Description: PGP signature
Re: ./method
I also like this notation.
However, as a side note, let me voice the opinion that the bad
reputation of Perl partially comes from the fact that it often looks
like line noise. I think everybody know this. Now there has been a lot
of discussion on finding different meanings for any two-character
combinations of ^/[EMAIL PROTECTED]~{}\ (I am sorry to say it that way). As a
Perl programmer I like this, but I am afraid that other programmers of
different languages (...who will burn in Hell... :-)), or newcommers
to Perl6 will have trouble even to pick up the basics. But again, this
is just a side note.
In this particular case, I like ./method because I don't like
$?SELF.method, which looks like my terminal is in UTF-8 and there is an
ISO-8859-2 character between $ and SELF :-))
- Cs.
A few days ago, when typing ./pugs,... You can guess the rest :)
I suggest
./method
to mean $?SELF.method, and
../method
Your opinions please! (I ask those who already responded off-list, to
repeat their opinion here)
Wonderful!
Re: ./method
(Note that ./ and ../ are prefix operators, and unlike .?, .*,
.+ and .=, cannot be used infix. In fact, it requires that ?, *,
+ and = be thought of as meta-operators to ., and from now on, to
./ and ../ as well, so you get ./+method. This isn't as complex as
it looks right now.)
Your opinions please! (I ask those who already responded off-list, to
repeat their opinion here)
Since new syntax is being suggested for these things, here is my
suggestion, very late in the discussion, but here it is anyway.
$_ is the topic; the only problem is that we have two topics here: an
immediate and a main topic. What if a method call binds the invocant to
*both* $_ and the bigger topic $__?
method foo($x){
# invocant accessible by both $__ and $_
for (1..3) {
# invocant accessible by $__ only
.bar(); # called on $_
$__.bat(); # called on the invocant
$?CLASS.bas();
}
}
I like this because things still look a little like a topic. This is not
better than $o/$O, except that $__ looks more like $_ (but maybe it looks
too much like $_, and that alone could invalidate this proposal).
Comments?
--abhijit
Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/
