On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote: : So, will "mutatingness" be a context we'll be able to inquire on : in the implementation of a called routine?
Probably not, but it's vaguely possible you could somehow get a reference to what is being assigned to, if available, and check to see if $dest =:= $src (where =:= tests to see if two refs point to the same object). But in general I think most "want" testing is just a way of making code run slow, because it forces tests to be done at run time that should be done at compile time or dispatch time. It's better for the optimizer if you can give it enough type hints and signature hints to decide things earlier than the body of the sub or method. : Or, could we provide a specialized distinct implementation : for mutating that would get called if .=X() is used? That is much more likely. In general if you don't define both an <op> and an <op>= then Perl can autogenerate or emulate the missing one for you. Now in the specific case of . and .= we don't exactly have a normal binary operator, because the right side is not an expression. So we may have to provide a way of marking a normal method as a mutator. Possibly we end up with method =sort (Array @ary) returns Array {...} # inplace method sort (Array @ary) returns Array {...} # cloning That works nicely with the .= vs . distinction, visually speaking. On the other hand, you might want to do the same with multi subs: multi sub =sort (Array @ary) returns Array {...} # inplace multi sub sort (Array @ary) returns Array {...} # cloning and then it gets a little more problematic syntactically because multis are called like subroutines: =sort(@array); We would have to allow an initial = at the beginning of a term. So far I've resisted doing that because I don't want @obj.meth=foo(); to become ambiguous, in case I decide to make the parentheses optional on method calls with arguments. If I did decide that, and we have terms beginning with =, it would not be clear whether the above meant @obj.meth(=foo()); or @obj.meth=(foo()); The = prefix notation also doesn't work very well for talking about the name of a routine: &=sort That looks an awful lot like a junctive assignment operator... >From a C++-ish perspective, the right thing to do is to differentiate not by the name but by the declared mutability of the invocant: multi sub sort (Array @ary is rw) returns Array {...} # inplace multi sub sort (Array @ary) returns Array {...} # cloning Or I suppose a case could be made for something that specifically declares you're returning one of the arguments: multi sub sort (Array @ary is rw) returns @ary {...} # inplace After all, it's possible to write a method that mutates its invocant but *doesn't* return it like a well-behaved mutator should. You don't always call a mutator in a void context--sometimes you want to be able to stack mutators: @array.=sort.=uniq; So you have to be able to return the mutant as well as mutate it in place. On the other hand, I'm deeply suspicious of a return signature that mentions a specific variable. What if the body says to return something else? Is that just ignored? Do we check it to see if it's the same item? So my guess is that it's probably better to have something more specific for the mutator "template". I think, actually, that I've convinced myself that a mutator should be marked in its name, and that it should generally be defined as a standard method rather than a multi sub: method =sort (Array @ary is rw) {...} # inplace This would automatically arrange to return the invocant. It would be illegal to use C<return> in such a routine. And I guess, since it's an ordinary method, we can leave out the invocant: method =sort () {...} # inplace with the assumption that the default invocant on a mutator would automatically be assumed "rw". If you do happen to want to define a multi sub mutator, then the syntax for calling it could be &«=sort»(@array) However, we really don't have to special case the = prefix syntax if we make it something like: method postfix:.=sort () {...} # inplace multi sub postfix:.=sort () {...} # inplace That's getting way up there on the ugliness factor. Might be worth a new operator category: method mutate:sort () {...} # inplace multi sub mutate:sort () {...} # inplace or method inplace:sort () {...} # inplace multi sub inplace:sort () {...} # inplace or method rw:sort () {...} # inplace multi sub rw:sort () {...} # inplace or method self:sort () {...} # inplace multi sub self:sort () {...} # inplace On the final hand, if people fall in love with both self:sort and =sort, we could have =sort be a shorthand for self:sort where it's unambiguous. On the (n+1)st hand, that says we could write it either as @array.=sort.=uniq or @array.self:sort.self:uniq Perhaps that's okay under TMTOWTDI. I actually find the shorter one more readable. But then calling it as a sub would always just be self:sort(@array); And then, .self:sort might or might not be preferred over .=sort : If we are performing some operation on : large data, and we know the end result is going to clobber the : current object, we could avoid making an extra copy. Yes, computer performance is desirable. but I think the biggest goal of the mutating operators is mental performance. The fact is that $a += 1; is much easier to understand than $a = $a + 1; : I suppose there is some danger here. What if I write a class : that I intend to have value semantics. That is, once an instance's : value is set at construction time, it never changes, although you : can get new instances by invoking its methods. BigInt would : work this way. I can imagine a Point class working this way - you : don't (necessarily) want two objects hanging on to a point, and one : of them to mutate it into a different value out from under the other : one. You wouldn't expect that behavior from other value objects such : as built-in strings. : : This points at mutatingness being aimed at the reference (variable) : not the referrent (value), unless it can be different in the case : of value-objects and container-objects... : : So, if we had a BigDataContainer class for which it *was* reasonable : to mutate it in place, and we wanted that behavior to trigger on .= : to do an in-place modification: : : $bigData .=applyBlockCipher($cipher, $key); : : would there be a way to do that without the extra copy implied in: : : $bigData = $bigData.applyBlockCipher($cipher, $key); : : while leaving : : $foo .=someOtherMethod(); : : equivalent to : : $foo = $foo.someOtherMethod(); : : when $foo's class or someOtherMethod() implementation doesn't do : anything special? We can autogenerate routines however we like as long as the metadata is there to decide how to do it. In this case any autogenerated <op>= is going to call the (presumably cloning) <op> and then assign the resulting reference back to the source. So the default would do what you want, I think. Going the other way, if you only define <op>=, then an autogenerated <op> would presumably .clone the object before doing the <op>= on it. It also may be that these can work a little differently if you know the underlying datatype is copy-on-write. Larry