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