in reply to Prototype for constant items???

Re: UPDATE2:

I can't see what's confusing you about \"1" resulting in a SCALAR - I remember reading somewhere, I think it's in one of the O'Reillys, but senility and alcohol together combine to prevent me from remembering exactly where, that a primitive means of constructing a constant relies on this - using idioms of the form: 

*PI = \3.14159;
*STR = \'Some string';
# etc.

[download]
Soooo, AFAICT, pre-declaring the literal as a constant solves your problem... 
use warnings;
use strict;
no strict qw/vars/;

*STR = \'Some string';
my ($str1, $str2) = (\'Some string', $STR);

sub foo(\$) { return }

eval { foo($STR) };
warn "$@";
eval { foo($str1) };
warn "$@";
eval { foo($str2) };
warn "$@";

[download]
Giving 
$ perl tst.pl
Warning: something's wrong at tst.pl line 10.
Warning: something's wrong at tst.pl line 12.
Warning: something's wrong at tst.pl line 14.

[download]
Doesn't it ?

A user level that continues to overstate my experience :-))

Replies are listed 'Best First'.
Re^2: Prototype for constant items???
by LanX (Saint) on Sep 25, 2009 at 13:39 UTC
    actually I don't wanna complicated workarounds to avoid simple errors .... :)

    Something like  join @a,@b is always ever wrong, but it's legal perl syntax.

    I'm wishing a possibility to restrict the input to for example "obvious" scalars. The way ref \"1" works is OK for me, because "1" obviously results in a scalar.

    It's only frustrating that the prototype mechanism doesn't support any way to achieve this.

    IMHO something like "accept every argument where ref argument results in XYZ" would facilitate a lot of error checking.

    Cheers Rolf

[reply]
[d/l]
[select]

      Checking the parameters with ref is good.

      Wherever it makes sense, I like to have the function detect that you've passed in an arrayref instead of a simple scalar, and then call itself foreach (@$param). Same with hashes. Lets you munge entire trees of values in one go, in a DWIM sort of way.

      Wherever that doesn't make sense, use croak and explain why the parameter is bad. You're not even limited to just "type". You can throw useful errors about much more subtle problems: "Temperature parameter cannot be less than absolute zero in call to set_thermostat() at monkey.pl line 42". Detailed and specific explanations of what went wrong are good.

      Don't limit yourself to prototypes, they rarely help. Just put in some good old preconditions with plain text explanations of what the caller did wrong.

      - SJ

      How to make perldoc.perl.org resizable too!
[reply]
[d/l]
[select]
        I agree with you that run-time checking is the next good thing to do, but I think you missed the point:

        I can't assure that I don't get erroneously the scalar of an array, without excluding constants!!!

        Neither at compile-time nor at run-time.

        Please try to give me a function that only accepts plain scalar values with "good old preconditions" and I'll be happy! ¹

        BTW: I'm not limiting myself to prototypes, I'm just trying to widen my possibilities...

        Cheers Rolf

        (1) well maybe with some caller parsing it's somehow feasible...

        UPDATE: I appended a practical use case with join to the startpost to make the problem less theoretical and easier understandable. Please try to give me a sub "newjoin" which croaks about this error!

[reply]

In Section Seekers of Perl Wisdom