develooper Front page | perl.perl5.porters | Postings from September 2011

Re: [perl #100190] RFE: fix sprintf to be consistent with printfand be useful!

Thread Previous | Thread Next
From:
Aristotle Pagaltzis
Date:
September 29, 2011 03:48
Subject:
Re: [perl #100190] RFE: fix sprintf to be consistent with printfand be useful!
Message ID:
20110929104839.GD1987@klangraum.plasmasturm.org
* 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About