On Sat, Jun 13, 2009 at 1:08 AM, Larry Wall<la...@wall.org> wrote:
> Nevertheless, for any major methods borrowed from Perl 6, I'm not
> inclined to change them that drastically. Much more likely to
> define them as sugar for the more general list operators:
>
> .push means .=append
> .unshift means .=prepend
> .splice means .=impend :-)
>
> or some such.
That makes sense to me. I'd very much like it if the fundamental
methods on most data types were non-mutating - string manipulation,
list munging etc. Along with having lazy lists, that gives us a good
dose of tricks from the functional world we can do, and with .= and
(hopefully) some clever bits in the compiler which can handle it
effectively (as in performance-wise), it's no hassle to convert any
non-mutator to a mutator. Syntactic sugar for really common mutating
cases, as in other methods which do 'the same thing but mutated' is of
course fine (particularly when they have sensible/familiar names,
which implies to my mind that the operation makes sense).
Although some things may be able to be implemented far more
efficiently if they know that they're being called with infix:<.=> and
not with infix:<.>.
method munge($self is ro:) { } # infix:<.> case
method mung($self is rw:) { } # infix:<.=> case
?
Marginally inspired by C++ const methods. Of course, a potential
problem here is that they might want different return types as well -
but maybe our multis are fine with that, and maybe this is just some
crazy dream caused by waking up too early on a Saturday morning and
thinking about Perl before breakfast.
Matthew
