> 16:50 < audreyt> Juerd: write to p6l and explain the ".." conflict,
The current long dot consists of a dot, then whitespace, and then
another dot. The whitespace is mandatory, which makes the construct at
least three characters long. Tripling the length of an operator, just to
make it alignable, is quite a lot.
Illustration:
$xyzzy.foo();
$fooz. .foo(); # doesn't line up, so we have to change the
# *previous* line!
$foo. .foo(); # this lines up again.
So we use:
$xyzzy. .foo();
$fooz. .foo();
$foo. .foo();
which is ugly and feels bad. It feels bad, because we're adding much
more whitespace (two character positions in total) than we had to
bridge. And it's a lot of work (many, many keystrokes!) to go back and
change something.
However, the whitespace in between cannot simply be made optional, as
then it would clash with the range operator. As ranges are even more
important than a sane "long dot" solution, the long dot had to change.
Larry indicated that changing the long dot would have to involve
changing the first character. The only feasible solution in the "tiny
glyphs" section was the backtick. I refrain from explaining why that
will widely be considered a bad idea.
Audrey cleverly suggested that changing the second character would also
work, and that has many more glyphs available. So she came up with
> and propose ".:" as a solution,
That's right, dot-colon. There are more glyphs available, but none of
them is nice like this. The basis is in regexes, where a colon means you
commit to have parsed the left side of the colon. That's how the colon
already reads in the indirect object notation, and the colon in
$foo.map:{...} can already be read.
So the actual solution is to make the method call operator not ".", but
".:". Of course, a lone "." still works and is the recommended style for
all simple method calls that don't have to be lined up. You can also
explain it as "." still being the base operator, where ".:" is a special
form. Whatever you like best :)
> and ". :" as an extension,
Of course, it wouldn't be a solution to the long dot problem if it
didn't allow an arbitrary amount of whitespace in between.
So, obviously, it does allow lots of whitespace in between. And, of
course, comments. If you really hate your future maintainer, you could
even put some POD in between.
$xyzzy.foo();
$fooz.:foo();
$foo. :foo();
Or, if you prefer:
$xyzzy.:foo();
$fooz. :foo();
$foo. :foo();
Or, if you actually LIKE the extra whitespace that the current long dot
mandates:
$xyzzy. :foo();
$fooz. :foo();
$foo. :foo();
> and ". +" as an generalization,
Of course, this works nicely with the operators it was inspired by, that
were also inspired by regex postfix operators: ".*", ".+" and ".?". They
can also contain whitespace in our proposal.
The dot-colon fixes another problem too. You couldn't line them up
anymore:
$foo.?bar();
$foo.baz(); # makes the ? look like part of the method name
So, now you can:
$foo.?bar();
$foo.:baz();
And an illustration with whitespace in between:
$xyzzy.:foo();
$fooz. ?foo();
$fo. *foo();
> and coexistence/removal of ". ." as a consideration
If we have dot-colon, we could keep the old long dot too. That would
work well with my preference for "..." as the first part of the old long
dot, as three dots stand out much better at the end of a line:
$foo...
.bar();
Though that isn't really dependent on the old long dot. It can live
separately. In fact, postfix "..." could be a generic "eat whitespace
and pretend it wasn't there" operator:
$foo...
.bar()...
.baz();
$foo...
.:bar(); # with normal old long dot, would be :bar(), looking like
# a pair, not a method call.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
