Erik Steven Harrison wrote:
> Just found this hidden in my inbox.
> I didn't think anyone was paying attention ;-).
Oh, we *always* pay attention. We just don't always respond. ;-)
>>What I most like about the C<is> syntax is (like methods in
>>OO Perl), it associates a meaningful *name* with each
>>deviation from standard behaviour.
>
> This is the argument that would win me over to the property syntax.
> Self documenting code is an admirable goal. But I wonder about our
> overuse of 'is'.
Think of it as punctuation. As a necessary alternative to the poor
overworked colon.
> The performance issues of a hash that lives with every variable aside,
They're not really relevant with C<is>, since it's compile-time in effect.
> it all looks the same to me. And I like different things to look different.
A fair point. My counterargument is that you're looking at the wrong bit.
C<is aka(...)>, C<is named(...)>, C<is constant>, etc all look very similar,
structurally. But so do C<$obj.foo()>, C<$obj.bar()>, and C<$obj.baz()>.
Yet we cope quite well with the OO syntax, because we look at the different
method names, not the shared dot introducer.
Properties have a great deal in common with methods, and so it really
should be surprising that they're invoked in a structurally similar manner.
Think s/<dot>/is/.
>>I find:
>>
>> sub hidden (str $name, int $force is aka($override)) {...}
>>
>>*much* more readable, since I can read it in English.
>
> Yeah . . . except I want at least single quotes around that darn $override.
> Required singles even. Having it be context sensitive to the type of property
> is WAY to subtle for me. And if $override is a reference I'd like that to DWIM (
> though I understand that I may be the only person for which that behavior is
>intuitive).
> And what happens with double quotes - a symref? Ack!
Then why don't you want single quotes around the C<$name> and C<$force>?
After all, they're not being evaluated there either.
The C<is aka> would be a form of auxiliary declaration, so it's quite as
reasonable not to put annoying quotes around it. It just means that the
parameter list of the property would be declared with one of Larry's
postulated C<is parsed(/<Perl.variable>/)> properties.
> If $force is aka(@override) is going to be a compile time error, then why can't we
> just $force is aka(override) and just carry the typing over.
So you can't stand a bare declarative variable, but you'd accept a bareword??? ;-)
The rason I'd do it the way I've suggested is precisely so that if someone's flawed
mental model causes them to write:
$force is aka(@override)
that *logical* bug in their thinking is detected and flagged.
> And if it's not a compile time error then what in Knuth's name
Now, now, no need to invoke deities! ;-)
> oh never mind - my head just exploded.
Hang in there. If these "mixed number" C<aka>s were allowed then I'd suggest
the semantics be that they indicate that *either* a scalar or array is
acceptable in the corresponding argument slot. The scalar variant of the
parameter would be bound to a scalar argument, or to a reference to an array
argument. The array variant of the parameter would be bound to an array
argument, or it's zeroth element bound to a scalar argument.
> -Erik
>
>>Damian
>
> PS - Ha! My name above Damian's :-)
Letting me get the last word, eh? Very kind of you. ;-)
Damian
