> -----Original Message-----
> From: Damian Conway [mailto:[EMAIL PROTECTED]
>
> Larry wrote:
>
> > On the other hand, I suspect most people will end up declaring it
> >
> > int method
> > self:rotate (int $a is rw) {...}
> >
> > in any event, and reserve the =rotate for .=rotate, which can never put
> > the = on the left margin, even if we let ourselves have whitespace
> > before POD directives. So maybe we just require self: for the
> declaration,
> > and forget about = there.
>
> Yes please!
>
> > It interacts badly with global names anyway.
> > Is it "*=sort" or "=*sort"? With "*self:sort" it's more obvious.
>
> Agreed. I'd *very* much prefer to see "reflexive" methods like this
declared
> C<self:methodname>. From a readability stand-point, if for no other
reason.
>
Boo, hiss.
Two things:
1- I'd rather use "inplace" than self.
2- I'd rather it be AFTER, than BEFORE, the name, because
method sort
method sort:inplace
reads, and more importantly SORTS, better than
method inplace:sort
method sort
To wit:
method :infix:<=>(Array, Array) returns Scalar
method :infix:==(Array, Array) returns Boolean
method :infix:!=(Array, Array) returns Boolean
method :infix:===(Array, Array) returns Boolean
method :infix:!==(Array, Array) returns Boolean
method :infix:x(Array) returns Array
method :infix:x:inplace(Array is rw)
### Note: How to handle [undef]? return-undef, or PHP-like push?
method :postfix:[](Array is rw, ?Scalar) returns Scalar
### Inplace-only?
method clear(Array is rw) returns Boolean
method compact(Array) returns Array
method compact:inplace(Array is rw)
### Inplace-only?
method delete(Array is rw, Int) returns WHAT, exactly?
method difference(Array, Array) returns Array #A-B
method differences(Array, Array) returns Array #(A-B) + (B-A)
method exists(Array, Scalar) returns Boolean
method flatten(Array) returns Array
method flatten:inplace(Array is rw) returns Array
method grep(Array, Code) returns Array
method includes(Array, Scalar) returns Boolean
method index(Array, Scalar) returns Int
method intersect(Array, Array)
method is_empty(Array) return Boolean
method join(Array, String)
method length(Array)
method map(Array, Code) returns Array
method pack(Array, String) returns String
method reverse(Array) returns Array
method reverse:inplace(Array is rw)
method rindex(Array) returns Int
### Boy are these likely to be wrong!
method sort(Array, ?Code) returns Array
method sort:inplace(Array is rw, ?Code)
### Inplace-only?
method splice(Array is rw, ?Int, ?Int, ?Array)
method union(Array, Array) returns Array
method unique(Array) returns Array
method unique:inplace(Array is rw)
### Inplace-only?
multi method fill(Array is rw, Scalar, Int, Int)
multi method fill(Array is rw, Scalar, Int)
multi method fill(Array is rw, Scalar, Array)
### Inplace-only?
multi method pop(Array is rw, ?Int) returns Array
multi method pop(Array is rw) returns Scalar
### Inplace-only?
multi method unshift(Array is rw, Scalar) returns Array
multi method unshift(Array is rw, Array) returns Array
### Inplace-only?
multi method push(Array is rw, Array) returns Array
multi method push(Array is rw, Scalar)
### Inplace-only?
multi method shift(Array is rw, Int) returns Array
multi method shift(Array is rw) returns Scalar
multi sub each(Array) returns Iterator # HOW does this work?
(Note also that :...fix sorts better than in-, post-, and pre-. I'd like to
suggest changing
them, since it costs nothing and results in a mild improvement in automation
behavior.)
> > Another interesting question, if the "postfix:.=foo" mess is defined
> > with as self:foo, should infix:+= be defined as self:+ instead?
> > In other words, should the <op>= syntax really be a metasyntax like
> > hyperoperators, where you never actually have to define a C<�+�>
> > operator, but the hyperoperator is always autogenerated from ordinary
> > C<+>? So basically any infix:<op>= gets remapped to self:<op>.
>
> I think that would be cleaner.
Alternatively, is there a valid reason to *need* to define your own
hyperoperator?
That is, can you code C< @a +� $x > better than C< @a.map {return $_ + $x}
>? I suspect that it's possible to do so, particularly for such simple cases
as assignment. (Hint: Persistent objects, database, one SQL statement per
assignment.)
So perhaps I should ask for an :infix:=� operator override?
> > On the other hand, it also means that
> > someone can say silly things like:
> >
> > $a cmp= $b
> > $a ~~= $b
> >
> > I suppose we could simply disallow meta-= on non-associating operators.
> > Can anyone come up with a non-associating binary operator that *should*
> > have an assignment operator? The basic definition of non-associating
> > seems to be that the type of the arguments is incompatible with the
> > type produced by the operator. Which is precisely the problem with
> > something like
> >
> > $a cmp= $b
> >
> > insofar as $a is being treated as a string at one moment and as a
boolean
> > at the next.
>
> I think it's "merely" a philosophical problem.
>
> After all, we don't complain when people write:
>
> $a = $a cmp $b;
>
> So should we complain when people write exactly the same thing, only as:
>
> $a cmp= $b;
>
> Stylistically, they're equally as abhorrent, but Perl users aren't
expecting
> the Stylish Inquisition.
>
So long as you allow modifiers in there, as:
$a cmp:i:n=8= $b;
I'm okay with it. Good luck with <=>=
> The real question is whether the two forms are equally likely to indicate
a
> logic error. One could argue that anyone who writes the first is more
likely
> just being (small-l) lazy, whereas writing the second probably indicates a
> "thinko". But then one could also argue that it's (small-l) lazier to
write
> the second than the first, so the second is actually *more* likely to be
> (small-l) laziness than error.
>
> There are also cases where something like:
>
> $a ||= $b;
>
> or:
>
> $a += $b;
>
> changes the type of value in $a. Should we flag those too?
> Currently we do warn on the second one if $a can't be cleanly coerced to
numeric.
> Would that be enough for C<cmp=> too, perhaps?
Data type conversion, especially for Scalar subtypes, should very definitely
be controllable by pragma.
> Damian
=Austin
