I can't prove you wrong, but to me it sounds extremely reasonable
that there'd be a lot of lines of code that rely on that behavior
exactly. You believe nobody is using fgets() to read, say, 3
bytes? Unless I'm missing something, whenever someone uses this
function to read an exact number of bytes (as opposed to reading a
full line) - his logic will now be broken.
As a quick reference, on the switch from PHP 3 to 4 (when the
popularity of PHP was maybe 1/20 of what it is today) every tiniest
breakage we thought would bother no one, has been noticed and
complained about. Frankly, I think this is a bigger breakage than
most of the stuff we broken in PHP 4 (but again, I may be missing something).
Re the argument name change, if you can find a better name for
argminusone, I'm all for it. I'm doubtful we can come up with
something good, but I think it's better to stay with the old behavior
and a somewhat bogus argument name than to break compatibility.
My 2c.
Zeev
At 22:59 14/11/2006, Sara Golemon wrote:
Antony Dovgal wrote:
On 11/14/2006 08:26 AM, Andi Gutmans wrote:
Sounds like something which indeed isn't worth breaking. Was this
intentional?
Sara says it was intentional, that's why I decided to write to the list.
I don't think such intentional breaks should take place in any PHP version.
It was quasi-intentional. The functions needed a lot of changes
related to PHP6 Unicodiness and I implemented "maxchars" to mean
"maxchars" rather than the appearantly expected
"maxcharsbutnotreallycausewedonotwantthelastcharacter".
As I told tony in IRC, I don't care if the behavior gets changed
back to 5.2 style, although I don't think this is a BC we need to
worry about keeping. I'll lay money that NOONE is relying on this,
and I challenge any of you to prove me wrong on that count.
If y'all do want maxcharsminusone behavior for the argument, fine,
but rename the arg to something else. maxchars means "I want this
many characters or less", not "I want one less than this many
characters{or less}".
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
