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 dw
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()
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
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
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 w
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, and
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:
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 $
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 .
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
http://convolution.nl/make_juerd_ha
.
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 ( Int
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 *def
> : ../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 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
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
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
Aaron Sherman wrote:
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 u
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 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 a
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
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.
./:metho
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 <[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, o
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 curren
On Sun, May 15, 2005 at 04:40:04PM +0200, Juerd wrote:
> Because of that, it is probably better to go with ./method not have ../method
Good. I was having a headache trying to convince myself ../method
was a good idea, but can't. Thanks for delivering me. :)
/Autrijus/
pgpPIwCGEgfd1.pgp
Descri
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 t
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
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 termina
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 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
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 s
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
(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
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-characte
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
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 convert
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:
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 requir
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
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 L
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:: namespac
41 matches
Mail list logo
