On 2008-Jun-2, at 3:30 pm, Jon Lang wrote:
 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.

I like "is rw($value)". There does need to be a way to tell whether a value was passed to it, even if that value was undef. Ah, it just occurred to me that rather than checking the $value, you should be able to check "want~~:($ is rw)".

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?

I would expect all of those to work the same way in either case. That is, anywhere the sub is used as an lvalue, it could pass the rvalue as a special arg, not just when using "=".

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.

OK; but I think that can be handled by a mutating sub -- assuming the issue is that the proxy-sub "sub foo is rw { blah; $proxy }" runs "blah" once and returns the proxy that can be assigned to multiple times, whereas a mutating sub would run "blah" every time you use it. But:

sub foo is rw($rval) { unless want~~:($ is rw) { blah }; $unproxy= $rval; }

In other words, the mutating-sub-way can do everything the proxy-way can (and more), as long as we can tell when being used in lvalue- context.

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?
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.

I agree with that; I'm just pondering whether we need the concept of "tying" any more, or whether FETCH and STORE can be thought of as standard methods for any object. In P5, not everything was an object, but everything is in P6 (or can be considered one, if you like objects), so it would be simpler to think in terms of one unified concept instead of two.

Of course, since subs are objects too, maybe all you need for an lvalue-sub is to override the FETCH and STORE methods it already has. But then the "is rw" stuff would simply be syntactic sugar to make doing so prettier.


Reply via email to