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
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
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
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
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:
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
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)
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
(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
For starters, about the only combination harder to hit with on
spanned hand might be ctrl-F5.
I've remapped my keyboard so that I push shift for numbers and leave
it off for the various symbols on the top row. ^ isn't hard to type
for me. (Plus, is it that hard to use two hands with shifted keys
Juerd 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.
I'm opinionless on the latter, since in my opinion cross-calling
supermethods (calling a
Abhijit Mahabal skribis 2005-05-15 9:10 (-0500):
$_ 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 $__?
(...)
I like this because things still look a little like a
Abhijit Mahabal wrote:
(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
On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd 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.
That's almost
On Sun, 15 May 2005, Juerd wrote:
I do think $__ looks too much like $_.
Yeah, lets drop that idea.
A bit better would be to not have
a bigger topic, but a higher topic, $-, but the problem with seeing
the invocant as a topic on another level, is that
inconsistency/asymmetry would be introduced
Larry Wall skribis 2005-05-15 7:32 (-0700):
(such as that it makes it too easy to use SUPER semantics rather than
NEXT semantics)
I'm not intimately familiar with the advantages and disadvantages SUPER
versus NEXT, but they may both be dangerous if used on a *different*
method.
Because of
On 5/15/05, Juerd [EMAIL PROTECTED] wrote:
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
Larry Wall [EMAIL PROTECTED] wrote:
On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd 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
On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
: Does this mean private methods will be called like this?
:
: ./:method()
No, I think that's still just
.:method()
Larry
Larry Wall skribis 2005-05-15 9:24 (-0700):
On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
: Does this mean private methods will be called like this?
: ./:method()
No, I think that's still just
.:method()
Both, depending on what you're calling it on.
./:method #
In reviewing S29 as it stands now, I see that many builtins both receive
and return boxed basic types. This seems like potentially spurious
overhead in some situations, while essential in others, so I wanted to
work out a set of rules for when boxed vs. unboxed types would be used
in core routines
On Sun, 2005-05-15 at 18:34 +0200, Juerd wrote:
I've been looking for a good moment to come with this, but there is
none, making this as good a point as any: I don't like the dot in
attributes, and the colon that replaces it.
If we have .method and .:method, then we should have $.attr and
Now:
Declaration ExplicitImplicit $_ $?SELF
has $.var | $obj.var \ .var \ ./var \
has $:var | $obj.:var \ .:var \ ./:var \
Consistent:
has $.var \ $obj.var \ .var \ ./var \
has $.:var \
On 5/14/05, Damian Conway [EMAIL PROTECTED] wrote:
Larry wrote:
I don't think we can allow this situation to stand. Either we have
to make != and !~ and ne transform themselves via not raising, or
we have to disallow negative comparisons on junctions entirely.
Opinions?
Making
On 5/15/05, Autrijus Tang [EMAIL PROTECTED] wrote:
On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd wrote:
I suggest
./method
to mean $?SELF.method
Sounds good.
class Person is Mortal {
has Weapon %.weapons;
...
method battle_choice (Monster $enemy) {
On 5/15/05, Luke Palmer [EMAIL PROTECTED] wrote:
multi sub infix:!= (Any|Junction $a, Any|Junction $b) {
!($a == $b);
}
Then it Just Works.
Also, that's the right way to provide a working != for any object
which defines ==. We all want that, right?
Ashley Winters
: ../method
:
: to mean $?SELF.SUPER::method, or however that's normally written.
That's almost terminally cute, but I like it. Unless someone can
think of a major objection (such as that it makes it too easy to use
SUPER semantics rather than NEXT semantics), let's go with it.
On 15/05/05 11:17 -0400, Rob Kinyon wrote:
On 5/15/05, Juerd [EMAIL PROTECTED] wrote:
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
.
On 15 May 2005, at 16:17, Rob Kinyon wrote:
Right now, P6 has $?SELF and I'm saying that instead of using $?SELF,
we should use $self wherever $?SELF would be used. $_ is still the
topic and would be the default invocant if you have .method($foo).
What I'm saying is that you can have
method (
Brad Bowman skribis 2005-05-16 9:56 (+1000):
Would it conflict with range + pattern? Or has that changed anyway?
No, ./ and ../ are prefix only, so they cannot clash with an infix
operator like ...
Juerd
--
http://convolution.nl/maak_juerd_blij.html
On 15/05/05 22:48 +0100, Matthew Walton wrote:
.
On 15 May 2005, at 16:17, Rob Kinyon wrote:
Right now, P6 has $?SELF and I'm saying that instead of using $?SELF,
we should use $self wherever $?SELF would be used. $_ is still the
topic and would be the default invocant if you have
On 5/15/05, Juerd [EMAIL PROTECTED] wrote:
Brad Bowman skribis 2005-05-16 9:56 (+1000):
Would it conflict with range + pattern? Or has that changed anyway?
No, ./ and ../ are prefix only, so they cannot clash with an infix
operator like ...
How would
print Foo while $self../method;
Larry Wall wrote:
On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
: Does this mean private methods will be called like this?
:
: ./:method()
No, I think that's still just
.:method()
This missing design rationale here is that the colon acts as part of the unary
operator:
Luke wrote:
Hmm. I'll just [mention] that if != is implemented like this:
multi sub infix:!= (Any|Junction $a, Any|Junction $b) {
!($a == $b);
}
Then it Just Works.
I'd be fine with the dwimmy version if that is the underlying rule, since then
the behaviour isn't a special case,
On Sun, May 15, 2005 at 08:30:06PM -0400, Rob Kinyon wrote:
: On 5/15/05, Juerd [EMAIL PROTECTED] wrote:
: Brad Bowman skribis 2005-05-16 9:56 (+1000):
: Would it conflict with range + pattern? Or has that changed anyway?
:
: No, ./ and ../ are prefix only, so they cannot clash with an
Damian Conway [EMAIL PROTECTED] wrote:
Larry Wall wrote:
On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
: Does this mean private methods will be called like this?
:
: ./:method()
No, I think that's still just
.:method()
This missing design rationale
On Sun, May 15, 2005 at 06:34:47PM +0200, Juerd wrote:
: .:method # $_.:method
It is almost certainly the case that you can't call a private method
of $_ unless it just happens to have trusted you, and since it's
such an unusual thing, calling into another class's private method
should have
On Sun, May 15, 2005 at 08:54:52PM -0400, Matt Diephouse wrote:
: Damian Conway [EMAIL PROTECTED] wrote:
: Larry Wall wrote:
:
: On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
: : Does this mean private methods will be called like this?
: :
: : ./:method()
:
: No,
On Mon, May 16, 2005 at 10:37:13AM +1000, Damian Conway wrote:
: Luke wrote:
:
: Hmm. I'll just [mention] that if != is implemented like this:
:
: multi sub infix:!= (Any|Junction $a, Any|Junction $b) {
: !($a == $b);
: }
:
: Then it Just Works.
:
: I'd be fine with the dwimmy
39 matches
Mail list logo
