Well, you started claiming an analogy between builtin functions and named operators. :)
from Prototypes
Because the intent of this feature is primarily to let you define subr +outines that work like built-in functions, here are prototypes for so +me other functions that parse almost exactly like the corresponding b +uilt-in.<P> 1. Declared as Called as 2. 3. sub mylink ($$) mylink $old, $new 4. sub myvec ($$$) myvec $var, $offset, 1 5. sub myindex ($$;$) myindex &getstring, "substr" 6. sub mysyswrite ($$$;$) mysyswrite $buf, 0, length($buf) - $off, +$off 7. sub myreverse (@) myreverse $a, $b, $c 8. sub myjoin ($@) myjoin ":", $a, $b, $c 9. sub mypop (\@) mypop @array 10. sub mysplice (\@$$@) mysplice @array, 0, 2, @pushme 11. sub mykeys (\%) mykeys %{$hashref} 12. sub myopen (*;$) myopen HANDLE, $name 13. sub mypipe (**) mypipe READHANDLE, WRITEHANDLE 14. sub mygrep (&@) mygrep { /foo/ } $a, $b, $c 15. sub myrand (;$) myrand 42 16. sub mytime () mytime
> But why would you want to make my() behave differently than foo(). That doesn't remove confusion or problems. It adds to them.
nope, don't think so. Already the fact that you can assign a list, i.e. my(LIST)=LIST is beyond the normal patterns of lvalue subs.
An operator working on lists of variables having a special behavior in scalar context is IMHO strange!
Cheers Rolf
In reply to Re^8: why doesn't "my ($a,$b)" return a list?
by LanX
in thread why doesn't "my ($a,$b)" return a list?
by LanX
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |