Design of the code classes
I wrote up a summary and some notes and posted at http://www.dlugosz.com/Perl6/web/code.html. Can we come to a definitive statement of the Callable/Code/Block/Routine types, relative to the hints that are in the synopses thus far? What I would like to do is get a consensus to write this up formally in my specdoc, and I'll also mark up the synopses files with the inconsistencies and proposed new wording, for Larry (the document owner) to have. --John
Re: Code classes
On Mon, May 02, 2005 at 05:42:47PM -0700, Larry Wall wrote: : We're still discussing it on @Larry, but I think we can make that work. Well, now I think .foo() won't work, since .foo should be reserved for a sub ref attribute to be consistent. But I think all we have to do is find some other character to use for self calls instead of ''. There are a number of candidates, and I can convince myself that there are good arguments for most of them, so now I just have to pick the one with the weakest arguments against it. :-) Larry
Re: Code classes
Larry Wall wrote: On Mon, May 02, 2005 at 05:42:47PM -0700, Larry Wall wrote: : We're still discussing it on @Larry, but I think we can make that work. Sorry if I don't know, but where or what is @Larry? I guess some IRC? Well, now I think .foo() won't work, since .foo should be reserved for a sub ref attribute to be consistent. But I think all we have to do is find some other character to use for self calls instead of ''. There are a number of candidates, and I can convince myself that there are good arguments for most of them, so now I just have to pick the one with the weakest arguments against it. :-) I'm not carping about the syntax but about the in my eyes unfortunate binding of the topic variable to one of the invocants. My chart should give the idea of the split between these two worlds. The invocants are OOish or typeish while the parameters are procedural. Has that binding been re-painted as well? BTW, what does $.foo outside of class scope mean? $.foo == $_.foo? How are parameters passed? $.foo( $arg, blahh )? -- TSa (Thomas Sandlaß)
Re: Code classes
Thomas Sandla writes:
Larry Wall wrote:
On Mon, May 02, 2005 at 05:42:47PM -0700, Larry Wall wrote:
: We're still discussing it on @Larry, but I think we can make that work.
Sorry if I don't know, but where or what is @Larry?
Ahh, you came in too late. I don't remember who coined it, but @Larry
is the array of Larrys, that is, the design team.
I guess some IRC?
No #Larry {yet, :-}.
Well, now I think .foo() won't work, since .foo should be reserved
for a sub ref attribute to be consistent. But I think all we have
to do is find some other character to use for self calls instead of ''.
There are a number of candidates, and I can convince myself that there
are good arguments for most of them, so now I just have to pick the one
with the weakest arguments against it. :-)
I'm not carping about the syntax but about the in my eyes unfortunate
binding of the topic variable to one of the invocants.
I agree with you there. $Larry has said that he wants `when` to work
at the top level in methods, which is the main reasoning for the topic
binding. Indeed, that might cause people to use .method to mean call
on self, and then get shot in the foot when they reorganize things, but
I think it would be easy enough just to teach them not to. If they do,
then they're the ones with the gun.
BTW, what does $.foo outside of class scope mean?
It means:
BEGIN { die Can't use \$.foo outside of class scope; }
:-)
Luke
Re: Code classes
Luke Palmer wrote:
Ahh, you came in too late. I don't remember who coined it, but @Larry
is the array of Larrys, that is, the design team.
Aha. What does [EMAIL PROTECTED] evaluate to? How do the elements of
@Larry communicate?
I agree with you there. $Larry has said that he wants `when` to work
at the top level in methods, which is the main reasoning for the topic
binding. Indeed, that might cause people to use .method to mean call
on self, and then get shot in the foot when they reorganize things, but
I think it would be easy enough just to teach them not to. If they do,
then they're the ones with the gun.
If 'when' were the single exception then setting $_ = $?SELF (note: copy
not binding) there when in method code should be doable for the compiler.
BTW, what does $.foo outside of class scope mean?
It means:
BEGIN { die Can't use \$.foo outside of class scope; }
That contradicts $Larry's statement: By the way, this probably goes along
with a policy of allowing $.foo, @.foo, and %.foo outside of the class as well.
These would not refer to the actual attribute, but would call $self.foo()
underneath (except in the class that actually defines the attribute).
OK, he has got a 'probably' there. Would it be the one character saver
$.foo == $_.foo outside class scope, $.foo == $?SELF.foo in methods
of derived (or even unrelated?) classes and direct access to the instance
variable in the class scope that has the corresponding 'has $.foo' declaration?
Regards,
--
TSa (Thomas Sandla)
Re: Code classes
On Tue, 2005-05-03 at 05:33, Thomas Sandlaß wrote:
Luke Palmer wrote:
BTW, what does $.foo outside of class scope mean?
It means:
BEGIN { die Can't use \$.foo outside of class scope; }
That contradicts $Larry's statement: By the way, this probably goes along
with a policy of allowing $.foo, @.foo, and %.foo outside of the class as
well.
These would not refer to the actual attribute, but would call $self.foo()
underneath (except in the class that actually defines the attribute).
OK, he has got a 'probably' there. Would it be the one character saver
$.foo == $_.foo outside class scope, $.foo == $?SELF.foo in methods
of derived (or even unrelated?) classes and direct access to the instance
variable in the class scope that has the corresponding 'has $.foo'
declaration?
If it's ever $_, then you have the problem where the code:
given $someobj {
when $.foo {...}
}
gets wrapped in a method later in the project:
class X {
method y {
given $someobj {
when $.foo {...}
}
}
}
Now you have two options: either it's ALWAYS $?SELF.foo because it's
inside a method (and thus, this code is now wrong), or it's only
$?SELF.foo if X or any ancestor has a $.foo, otherwise it's $_.foo.
I like the idea that $.foo ALWAYS means the $.foo in the current class.
Anything else gets very ugly later on.
On a side note about auto-accessors, if I say:
class X {
has $.foo;
}
class Y is X {
has %.foo;
}
What happens to the accessors for X.foo?
If there's no current plan, my suggestion would be that every
auto-accessor has an alias of the form TYPE_NAME. That is, these hold
true:
has $foo; # Gets .Any_foo
has int $foo; # Gets .int_foo
has @foo; # Gets .Array_foo
has @foo is MyArray; # Gets .MyArray_foo
has $foo does X; # Hmmm... probably just .Any_foo
These should be automatically overridden by explicit method declarations
in this OR an ancestor class (to avoid mysterious bugs when you forget
that your $.foo is going to override your Any_foo method that has
nothing to do with an accessor), but should override inherited
auto-accessors... which of course means having to keep track of why a
method was created in the metaclass, but I don't think that's too hard.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Code classes
On Tue, May 03, 2005 at 07:59:19AM -0400, Aaron Sherman wrote:
: I like the idea that $.foo ALWAYS means the $.foo in the current class.
: Anything else gets very ugly later on.
Well, since I'm not going with for self, I'm probably not going with
the $.foo meaning anything outside of the class either.
: On a side note about auto-accessors, if I say:
:
: class X {
: has $.foo;
: }
: class Y is X {
: has %.foo;
: }
:
: What happens to the accessors for X.foo?
Overridden just like any such method.
Larry
Re: Code classes
On Tue, 2005-05-03 at 08:07, Larry Wall wrote:
On Tue, May 03, 2005 at 07:59:19AM -0400, Aaron Sherman wrote:
: On a side note about auto-accessors, if I say:
:
: class X {
: has $.foo;
: }
: class Y is X {
: has %.foo;
: }
:
: What happens to the accessors for X.foo?
Overridden just like any such method.
Are has declarations ordered as they appear?
That is, does:
has $.foo;
has %.foo;
give me an accessor for %.foo or for whatever one happened to be
declared last?
NOTE: Either way, I think the above should at least issue a warning that
you're overriding the definition of the auto-accessor declared within
the same class definition, and the same should probably happen with
composition sources (though not inheritance). This is implied in S12
when it says that roles auto-detect conflicting methods, but should
explicitly refer to attributes as well.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Code classes
On Tue, May 03, 2005 at 08:29:22AM -0400, Aaron Sherman wrote:
: On Tue, 2005-05-03 at 08:07, Larry Wall wrote:
: On Tue, May 03, 2005 at 07:59:19AM -0400, Aaron Sherman wrote:
:
: : On a side note about auto-accessors, if I say:
: :
: : class X {
: : has $.foo;
: : }
: : class Y is X {
: : has %.foo;
: : }
: :
: : What happens to the accessors for X.foo?
:
: Overridden just like any such method.
:
: Are has declarations ordered as they appear?
:
: That is, does:
:
: has $.foo;
: has %.foo;
:
: give me an accessor for %.foo or for whatever one happened to be
: declared last?
Neither--I'd think that'd be a fatal compile-time error.
: NOTE: Either way, I think the above should at least issue a warning that
: you're overriding the definition of the auto-accessor declared within
: the same class definition, and the same should probably happen with
: composition sources (though not inheritance). This is implied in S12
: when it says that roles auto-detect conflicting methods, but should
: explicitly refer to attributes as well.
Probably.
Larry
Re: Code classes
On May 3, 2005, at 00:04 , Luke Palmer wrote: I agree with you there. $Larry has said that he wants `when` to work Shouldn't that be @Larry[0]? Cheers, David smime.p7s Description: S/MIME cryptographic signature
Re: Code classes
On Tue, May 03, 2005 at 09:00:49AM -0700, David Wheeler wrote: : On May 3, 2005, at 00:04 , Luke Palmer wrote: : : I agree with you there. $Larry has said that he wants `when` to work : : Shouldn't that be @Larry[0]? That depends on whether you think the rest of them are pushy or shiftless. :-) Larry
Code classes
HaloO,
I don't know if this is usefull and if it is were this information
should be put. I've reworked the Code class chart from A06 to look
as follows:
invocant(s) : Code
_ :__ ___|___
| |: | |
SubMethod Method : SubBlock
___|: |___
| |: | |
Rule |: | Macro
|:__|
|:
MultiMethod :
role Code {...}
role Return{...}
role Dispatch[ ::How ] {...}
class Block does Code
class Sub does Code Return
{...}
class SubMethod does Code Return Dispatch of Class
{...}
class Method does Code Return Dispatch of Object
{...}
class Macro is Sub
{...}
class Ruleis Method
{...}
class MultiMethod is Method Sub does Dispatch of List
of Object
{...}
The vertical line of colons divides the methods from the subs basically.
This mirrors the declaration syntax of the invocants which are left of
the colon in a signature. The three underscore variables $_, @_ and %_
are right of the colon in my understanding and this is the main reason
for this mail: aliasing $_ in methods to the first invocant would badly
mix these two concepts!
Comments?
--
TSa (Thomas Sandlaß)
Re: Code classes
Hi,
Thomas Sandla wrote:
the main reason for this mail: aliasing $_ in methods to the first
invocant would badly mix these two concepts!
I think so, too.
I'd like to see:
$.foo# attribute of $?SELF
@.foo# ditto
%.foo# ditto
.foo# method of $?SELF
.foo# method of $?SELF
$_.foo# method of $_
This means that we've to write two additional letters in given {} and
map {} and somesuch...
@foo.map:{ $_.method 42 }
given $foo { $_.foo(42); $_.bar(23) }
...but it also means that
* . as secondary sigil ($.foo, @.foo, %.foo, .foo) is
consistent (always refers to $?SELF), and
* you don't have to use $self in methods again only because
you are (implicitly or explicitly) binding $_ to something
else.
IMHO, this advantages are worth the two extra chars.
--Ingo
--
Linux, the choice of a GNU | When cryptography is outlawed, bayl bhgynjf
generation on a dual AMD | jvyy unir cevinpl!
Athlon!|
Re: Code classes
On Mon, May 02, 2005 at 06:22:03PM +0200, Ingo Blechschmidt wrote: .foo# method of $?SELF .foo# method of $?SELF $_.foo# method of $_ We could also define them as: .foo # method on $?SELF .foo# method on $_ $_.foo # method on $_ The .foo syntax is very special, after all, so you can't really be consistent with it. I prefer it be the topic, in any case. -- wolverian signature.asc Description: Digital signature
Re: Code classes
On Mon, May 02, 2005 at 11:29:49PM +0300, wolverian wrote: : On Mon, May 02, 2005 at 06:22:03PM +0200, Ingo Blechschmidt wrote: : .foo# method of $?SELF : .foo# method of $?SELF : $_.foo# method of $_ : : We could also define them as: : : .foo # method on $?SELF : .foo# method on $_ : $_.foo # method on $_ : : The .foo syntax is very special, after all, so you can't really be : consistent with it. I prefer it be the topic, in any case. We're still discussing it on @Larry, but I think we can make that work. There are some ambiguities with .foo that depend on the declaration of it, but those can probably be resolved based on that declaration. This proposal is also consistent with the first invocant setting the topic, so when still works inside a method. So paint me back into the .foo == $_.foo camp this week, and now the .foo == $self.foo camp can start carping again. :-) By the way, this probably goes along with a policy of allowing $.foo, @.foo, and %.foo outside of the class as well. These would not refer to the actual attribute, but would call $self.foo() underneath (except in the class that actually defines the attribute). It seems to me that this would facilitate cut and paste of code, as well as the possibility of moving the attribute declaration to or from parent classes transparently. (To give credit where it's due, this was inspired by someone's misreading of S12 on PerlMonks a month or so ago.) Since the compiler is figuring out whether $.foo means an attribute or a method call on your behalf, to force a virtual call in the class itself, you'd have to say $self.foo(), which seems like a decent safety feature to me, insofar as it makes it harder to accidentally call yourself in an infinite regress. Which probably means that (just like $.foo) the .foo is devirtualized in any class that defines method foo, or we're back to the too-easy infinite regress. I think it probably works... Larry
