David Green wrote:
> Jon Lang wrote:
>> If a routine is rw, you may optionally define a single "slurpy scalar"
>> (e.g., '*$value') in its signature. This scalar counts as the last
>> positional parameter, much like slurpy arrays and hashes must be declared
>> after all of the positional parameters have been declared. You do not need
>> to pass an argument to it; but if you do, you may do so in one of two ways:
>> through the usual arguments syntax, or via assignment syntax.
>
> The only objection I have to making it a positional parameter is that then
> you can't have other optional positionals before it. (Also, doesn't the
> '*$value' notation conflict with a possible "head" of the slurpy array?)
Good points. I had overlooked the "head of the slurpy array" concept.
That said, it might be reasonable to insist on something like
'*($head, @body)' in a signature to represent a slurpy array with
specific variables assigned to the leading elements. Or not...
The bit about optional positionals is well taken.
> I'd rather make it named so it doesn't interfere with other args. Or have
> it separate from named/positional args altogether; if something has a
> meaning of assignment, then it should always look like "foo = 42" and not
> like "foo(42)". (The latter is just an ugly workaround for languages with
> incompetent syntax -- we don't want Perl code to look like that because Perl
> isn't like that.)
OTOH, TIMTOWTDI. I'm not inclined to force one particular syntax - be
it 'foo = 42' or 'foo(42)' - on the programmer; let him choose which
dialect he prefers. As such, it would probably be better to provide
some means of identifying a single named or positional parameter as
the gateway for an assignment. Perhaps this could be handled through
rw?
sub foo($value?) is rw($value) { ... }
Or something to that general effect. The parameter in question must
be optional and cannot have a default value, so that a test of whether
or not the parameter is actually there can be used to determine
whether or not to operate like FETCH or like STORE.
>> If an assignable routine does not have a slurpy scalar in its signature,
>> it operates exactly as currently described in S06: it returns something that
>> is assignable, which in turn is used as the lvalue of the assignment
>> operator.
>
> Does this [with no slurpy scalar to pick up the rvalue]:
>
> sub foo () { ...; $proxy }
>
> give us anything that you couldn't get from:
>
> sub foo ($rval is rvalue) { ...; $proxy = $rval }
(I'm assuming that both of these subs are rw.)
Yes. infix:<=> isn't the only operator that assigns values to rw
objects: so do the likes of infix:<+=> and prefix:<++>. As well, any
function that accepts a rw parameter will presumably end up writing to
it somewhere in its code; otherwise, why declare the parameter as rw?
Note, BTW, the difference between passing a proxy object as a
parameter and passing a mutating sub as a parameter: in the former
case, you call the lvalue sub once in order to generate the proxy
object, and then you pass the proxy object as a parameter; in the
latter case, you don't call the mutating sub: you essentially pass a
coderef to it, and then call it each time the function in question
attempts to read from or write to it.
(By "mutating sub", I mean a routine that handles the assignment
itself, along the lines of what you and I are discussing.)
>> [...] sub foo () is rw {
>> return new Proxy:
>> FETCH => method { return .() },
>> STORE => method ($val) { .($val) },
>> postcircumfix:<( )> => method ($value?) { yadda }
>> }
>
> Incidentally, now that Perl is all OO-y, do we need tying/proxying like
> that, or can we just override the "=" method on a class instead? Is there
> something different about it, or is it just an alternative (pre-OO) way of
> looking at the same thing?
FETCH and STORE are not pre-OO; they're pre-'user-defined operators'.
It's possible that in perl6, 'STORE' could be spelled 'infix:<=>'; but
then how would 'FETCH' be spelled? And doing so would require that
your storage routine return a value, even if you never intend to use
it. No; I prefer 'STORE' and 'FETCH' as the basic building blocks of
anything that's capable of working like a rw item.
--
Jonathan "Dataweaver" Lang
