Front page | perl.perl5.porters |
Postings from November 2011
Father Chrysostomos via RT wrote:
>
> Consider sprintf(get_format(), @args). get_format might return
> something else in list context. That’s the kind of breakage we don’t want.
>
> Also, does your experiment really work, or do you mess up the stack in
> cases like this?
>
> @a = ('%d', sprintf());
>
>> If anyone needs a compat layer,
>> I imagine it's trivial enough to provide through
> Classic::Perl/Modern::Perl,
>> or somesuch.
>
> What would prototype(\&CORE::sprintf) return?
>
----
Is there any reason why not to go through a 'warning cycle'; where
where it is warned that the prototype will change so it will be useful)?
Any anyone relying on the non-useful syntax, should be warned to change code?
Language features DO change with a deprecation cycle...
Also, in the case of sprintf(getformat(), @args)...
if get format returns somethign else in 'list context', then wouldn't
sprintf have thrown an error ? I.e. if the 1st arg is supposed to be a
scalar, 'getformat()' doesn't look like a simple scalar',
I.d. "push $foo, blah", where "$foo" contains a ref to an array, doesn't
work. It has to be a type "@", Since it is supposed to be a scalar,
then a deprecation cycle could throw a warning if \$ isn't met for the 1st
arg to sprintf...telling them to make sure it doesn't rely on 'wantarray'.
Since havin these two proglets return different results is nothing
but confusing and would drive anyone in testing crazy:
> perl -e '
sub x { wantarray ? "%d%s":"%5.2f%s"}
print sprintf (x(),2.7,"\n");
'
2.70
> perl -e '
sub x { wantarray ? "%d%s":"%5.2f%s"}
printf (x(),2.7,"\n");
'
2
---
I mean you pass a format to sprintf, and it prints out one thing,
but you pass it to printf, and it prints out something else?
But this ONLY happens in perl (not in C or other langs supporting both)?
That really drives home the point about perl being unsupportable due
to quirkiness.
Thread Next