> -----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