Front page | perl.perl5.porters |
Postings from September 2011
* Linda Walsh <perlbug-followup@perl.org> [2011-09-27 22:40]:
> From the manpage: (perfunc on sprintf).
>
> Unlike "printf", "sprintf" does not do what you probably mean when
> you pass it an array as your first argument. The array is given
> scalar context, and instead of using the 0th element of the array as
> the format, Perl will use the count of elements in the array as the
> format, which is ***almost never useful***.
>
> I would assert that this behavior goes against the "spirit of perl" to
> "always do the right thing". To do something that is "almost never
> useful" can "almost never be the right thing".
>
> Is there some **REAL** good reason why sprintf should not behave/ be
> compatible with printf?
No. There isn’t.
> I just wasted eh...maybe 10-15 minutes concocting a "printf" statement
> -- that I wanted to print to a variable, that would be passed the
> format and args in array, only to discover this *wart*.
Sorry for the time you wasted.
> **Either that, or** have 'printf' be able to print to a variable!
> (which is a bit 'lame', considering that's the point of sprintf).
>
> Why would the implementation / behavior of sprintf be different than
> printf. The whole point (I thought) was to be able to redirect output
> to a string instead of a file handle.
There is no good reason. It just is.
> If that's is not the point then a workaround, (actually, it would be
> a more generally purpose solution), would be to implement/allow:
>
> open($handle, \$myvar, ">");
>
> then I could printf $handle. Could even:
>
> open($handle, \$myvar, "<>");
> print $handle "hello world\n";
> seek $handle 0,SEEK_SET;
> while(<$handle>) {
> print
> }
> (out:)
> hello world
>
> .. and get file-semantic behavior from a var...
>
> I actually like this 2nd idea
That’s gross. Please don’t do that. Think of the poor wretch who will
work on the code after you.
> but it DOESN't mean the 'wart' on sprintf's implementation should
> remain.
Neither does it mean the wart should change. It’s not relevant.
If the behaviour of sprintf were to change, then a lot more people than
you would have a lot more than 15 of their minutes wasted; so more’s the
pity that it has to stay.
> So *WAS* there some reason to make sprintf incompat w/printf in
> syntax-functionality? Doesn't seem to make alot of sense and seems to
> be an unnecessary resriction.
It’s just an accident of history.
> (I really was under the 'illusion/misunderstanding', that sprintf and
> printf were 'identical' except one took a file handle and the other
> sent output to a var...*doh!* (hits self over head?))...
Welcome to the wonderful world of software, full of annoying surprises
like that. Software sucks.
> BTW -- would it be 'useful' for me to submit an RFE for my 'side
> comment above'? I've thought about it's desirability before.
>
> ***Given***, the increases in available memory, being able to use
> a meg or more of 'memory' in a "var" as a "scratch file", doesn't seem
> at all like an unreasonable feature...
It’s not relevant.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Thread Previous
|
Thread Next