> Larry Wall:
> # On Wed, Apr 23, 2003 at 10:28:45AM +1000, Damian Conway wrote:
> # : Brent Dax asked:
> # :
> # : >Which of the following (if any) is valid?
> # : >
> # : > $foo.{bar}
> # : > $foo .{bar}
> # : > $foo. {bar}
> # :
> # : The first certainly is and in fact, since there's no
> # ambiguity, I believe
> # : all three are.
> #
> # I think the third should be illegal (until someone defines
> # themselves a postfix:. operator).
>
> If you aren't going to require a lack of whitespace around e.g.
> C<infix:+>, why require it around C<infix:.>?
This is perfectly legal:
$foo . bar;
> Or are you suggesting that this is really a restriction on
> C<circumfix:{}>? If so, why forbid it around C<circumfix:{}> but not
> around C<circumfix:[]> or C<circumfix:()>? (Or is it forbidden around
> them too?)
I think it is. That way we can have:
print (myfunc $a, $b), "\n"
and
print(myfunc $a, $b), "\n"
Do different things, and have them both do what you expect. It's
still up in the air, though.
No postfix operators can have whitespace before them, just like in
Perl 5. And since {} is really a postfix, not a circumfix (that's
code and hash constructor) operator, it creates no exception.
I also don't think it's possible to write these such subscripting
operators with operator: notation (not to say it's impossible to add
new subscripters...)
> Perhaps we need a new type of operator, along the lines of C<indexer:>,
> which takes two arguments (object and index) and has the whitespace
> restrictions on it?
Kind of a postfix: circumfix: combination. I wonder whether it'll be
a common enough operation to define new subscripters to add this new
type. Probably not.
OTOH, it might be common enough that people override these operators
to allow it. I'd call it C<subscript:>, though.
Luke
Thread Previous
|
Thread Next