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