=?iso-8859-1?Q?Dav=ED=F0?= Helgason writes:
: I _really_ think dot-syntax would make perl prettier as well as make it
: more acceptable to the world of javacsharpbasic droids. Which is some
: kind of goal, no?
Consider it a given that we'll be using . for dereferencing. (Possibly
with -> as a synonym, just for Dan. :-)
: I suspect that we will never agree on anything here though.
I suspect we will. :-)
: Which of qw[~ ++ +~ + &] do we dislike the least? Using + would be
: nice, but introduce no end of problems with number/sting behaviour. '&'
: is too much like a certain unpopular language. And there was no end to
: the quabbling :(
++ is out becuase you can't have the same operator as both postfix and infix.
& is out because it'll stay bit-fiddly.
+ is out because it will add numbers.
+~ is out because I'd really like to have a single character for something
as common as concatenation.
(And juxtaposition is out because we're not going to destroy indirect
object syntax
I'm thinking concat will be ~. Furthermore, I'm thinking unary ~ will
be stringify, and unary ^ will be bit complement, on the theory that
bit complement is like xoring with 0xffffffff. And unary + will be a
numify, not a no-op.
: If we can make the concatenation into something else, we free the dot to
: do "string".length() and innumerable other niceties.
Indeed. Though of course that's not related to the syntax of . vs ->, which
could be taught to do the same thing.
: ps. What do you think about the following sentence: "we should steal
: more from ruby"? a) disgusting, b) uninteresting, c) clever, d)
: wonderful.
Well, whatever you think, we would have to steal it from the 1/3 of
Ruby that wasn't stolen from Perl. :-)
: pps. if ($_ === qw(b c d)) {
: "=== 'is in' operator",
: "dot operator remapped to mean",
: "objectspace array/iterator as in ruby, giving access to all existing
: data (but of course more complete than rubys rather flaky
: implementation",
: }
If we don't install such features directly, we at least want to make it
easy to install them. For instance, we'll definitely have easy ways
of writing code blocks that can function as iterators. And it would
be relatively easy to install a universal .each method that calls such
a code block, so you could, if you like, do a Rubyesque thing like
@dogs.each { $^.bark };
Depending on how HOF rules end up interacting with method prototypes,
we might even get:
@dogs.each $^.bark;
But it's probably clearer with the curlies. On the other hand, it's
possible that if @dogs (as an array) doesn't have a bark method, but
each Dog scalar does, then
@dogs.bark;
might do the right thing. I dunno about that yet. We can't just
assume the method is distributed over the array, or we won't be able to
get to methods resembling length(@dogs).
Larry
