Front page | perl.perl5.porters |
Postings from September 2011
Aristotle Pagaltzis wrote:
> * Linda Walsh <perlbug-followup@perl.org> [2011-09-27 22:40]:
> Is there some **REAL** good reason why sprintf should not behave/ be
> compatible with printf?
>
> No. There isn’t.
----
I'm glad you agree, it's a bug in the design of the language.
>> 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.
----
I did emphasize the trivial amount of time
I wasted... i.e. it wasn't a huge deal...but I realized how ugly
the problem was. Literally, I had
a routine that just passed an optional error code and list, where the
first arg could be a format or not, to a general error routine -- then
I realized I really wanted to call DIE instead of sprintf and exit, and
massage the string to interpret the error code as an '$ERRNO' in a string
context.. The massaging part was doable, but to get a string w/formatting
that didn't use printf it really seemed like I should be able to take the
LIST comprised of either a simple string, or a format followed by it's args
that was located in the rest of the @ARGS -- that I had been passing
to printf in "printf STDERR, @ARGV" => "die sprintf @ARGV";
In C, those calls are much more parallel, with different names
to indicate what optional args are at the beginning, but other
than the otional args...they all take a uniform (same type) list
of 'char * format, ...'.
Since sprintf and printf both are documented to be implemented
on top of the local [POSIX-compat] C library, then a difference
in their invocation, from the documentation, would be an error.
> There is no good reason. It just is.
---
Usually those are things that need to be fixed. When I was
told stuff like that as a child, it usually involved religious
issues that I questioned and ultimate refused to accept.
>
> That’s gross. Please don’t do that. Think of the poor wretch who will
> work on the code after you.
---
That's, **usually**, me. When I do something that is less than
str8 forward, I try to make sure it is well documented enough
that I'll understand it in 'N' months, as in 'N' months,
I'll remember nothing about why I did such -- have had it happen
too many times NOT to document such. But it would have to be that
it was algorithmically the right choice (more efficient, flexible),
not just for the sake of doing it.
>
>> 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.
Of course it is relevant. If something is needlessly broken and
can be fixed, why would you just choose to live with it? If humans
took that attitude as a whole, society would never change.
>
> 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.
----
As demonstrated by later example, trying to use it's existing behavior
in any meaningful way fails, so there is an extremely low probability of
any existing code breaking if such a change were to be made. There have
been other changes in perl code where old features have been deprecated
and changed that would have been FAR more likely to cause an incompatibility
that were changed because those features were considered 'warts' or
roadblocks to forward progress. There was no 'pity' for them. There
was only change and 'deprecation' when needed.
>
>> So *WAS* there some reason to make sprintf incompat w/printf in
>> syntax-functionality?
> It’s just an accident of history.
----
That you agree it's a mistake makes moving forward a far
easier task...otherwise, perl 5.12.0 would be bound to the same feature
set as 4.0, which fortunately, is not the case.
Linda
Thread Previous
|
Thread Next