in reply to -foo not readonly in fun(-foo => 1) in perl v5.8.7

I wanted to use Scalar::Util::readonly() to help distinguish between foo( 1,2,3) and foo( -one => 1, -two => 2, -three => 3),

That brings to mind "and I wanted a pony".

If you had come to me with that idea, I would have told you that you need to solve your problem in a different way. Even if you hadn't already found out that your trick is broken for some environments, I would have warned you that your idea is inherently fragile. It will be broken by a matter of optimization within Perl. There is no guarantee of the behavior that you assumed.

It is also extremely fragile in the face of simple changes to how your code is used. You should feel guilty considering making code that breaks between these two usages: 

    foo( -bar => 1 );

    my %args= ( -bar => 1 );
    foo( %args );

[download]

I think the better alternative is nearly obvious so I won't spend time describing it at this time.

- tye        

Replies are listed 'Best First'.
Re^2: -foo not readonly in fun(-foo => 1} in perl v5.8.7 (wishes)
by Jenda (Abbot) on Apr 20, 2008 at 08:23 UTC

    I don't want a pony. Don't have a place to put it. Prettymuch anything you do with named parameters in Perl, except for requiring their use and forbiding positional parameters completely, is fragile in one way or another.

    If by the better alternative you mean 

    foo( 1, 2, 3);
foo({ one => 1, two => 2, three => 3}); #with or without dashes

    [download]
    then this is fragile if the first positional parameter may be a hashref.

    Besides ... I would not feel guilty about that example ... that call doesn't look like a named-parameters call so it's not one. I can live with that. On the other hand if there was a way to distinguish between -foo and '-foo' that would work as well ... it's very unlikely that anyone would ever write $stringvar = -foo; or $stringvar = -$otherstring.

    Apart from being unable to tell between one positional hashref and several named params in foo({ -one > 1, -two => 2}); there is one more reason I don't want to do that. With foo( inparam => 31, outparam => $var) I can modify the $var from within foo(), with foo({ inparam => 31, outparam => $var}) I could not. While mostly I do think that functions should take (readonly) parameters and return some value(s), if possible without side effects, in case the subroutine is a wrapper of a database's stored procedure without output parameters, I do need to allow that. And I do not really like foo({ inparam => 31, outparam => \$var}).

    Jenda
    Support Denmark!
    Defend the free world!

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom