Darren Duncan skribis 2005-06-18 11:40 (-0700):
> item invocation syntax was exactly the same but with the
> consideration that all private items have a ':' as the first
> character in their otherwise alphanumeric names (the ':' looks like
> part of an operator but it isn't).
Except for attributes, which play a different game: the colon comes
*instead* of the dot as the twigil, while the accessor method gets : in
front of its name. If I recall correctly, the syntax is very misleading
in that it is NOT part of the name.
I don't like the inconsistency.
> PUBLIC PRIVATE
> ---------- ----------
> ./method() ./:method()
./:method is what I originally suggested along with my suggestion of
./method itself. I strongly dislike that .:method would work on $?SELF
and I also strongly dislike the contrived and false
two-\W-characters-mean-invocant-otherwise-it's-$_ rule. (It'd be true
(but would still feel artificial) if .+method would also use the
invocant. Which I pray is not the case.)
I do not want there to be any indication of there being two defaults and
that there is a way to select the other default. ./ is an operator by
itself and not the combination of . and /, and it cannot be used infix.
There is only ever one default variable|object in syntax, and that is
$_.
I'd like the colon to be part of the name, like underscore is used in
Perl 5: outside access is discouraged but entirely possible. I don't
think ANY syntax should be special cased for a method, just because it's
private. That doesn't mean there can't be a warning (warnings are not
syntax), and in fact a warning is all there should IMO be.
This means these public-private equivalency pairs exist:
$foo.bar $foo.:bar
.bar .:bar
./bar ./:bar
$.bar $.:bar # I wouldn't mind if $:bar were an *abbreviation*
.+bar .+bar
./+bar ./+:bar
(People could introduce other prefixes (although the number of available
characters is very limited) for other accessability indicators, like
perhaps [EMAIL PROTECTED] to allow web access.
> [EMAIL PROTECTED]() .@:method()
In Perl, @ has a VERY strong association with arrays, so except for
specialised frameworks, I recommend against using it for other purposes.
> .>method() .>:method()
I think > has just enough purposes, and that it should be left alone
now.
> gt
=> pair
==> pipe
<> qw
<<>> qw
+>, ~> shift
->, <-> sub
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
