fffggg

One letter strings evaluate as true. This would only be false for a last name comprised of the single digit '0'

"It is not pedantry; one cannot claim to have written the KJV version"

Sure one can. In fact, copyright has nothing to say regarding plagiarism. US copyright only prevents the copying of a work. I could claim to have authored Star Wars, the Bible, and your post -- copyright does not provide you recourse against this so long as I do not /copy/ them.

"The text is in the public domain but it is still covered by copyright."

No, it is not. Text in the public domain is not covered by copyright according to US law. Copyright ONLY applies to copies and incorporation into derivative works in the USA.

I apologize for being contradictory but you are completely wrong on both points here.

NKJV, the bible one typically finds in the USA, was edited and published in 1979 and is most certainly under copyright as a whole. In general, translations or adaptations of a work are under their own separate copyright.

Your overarching point that some things have false (or partially false) notice on them is accurate -- however the point that copyright law is subtle and often unclear in its details is equally valid.

I did not say it was "impossible," I said it would be "utterly unusable."

I am happy to see you agree with me.

- automatic integer-to-float comparison to accommodate bigger integers. A horrible hack to squeeze a little extra performance in naive benchmarks in computers with no native 64 bit integer support. This really makes no sense whatsoever now and may have had some partial justification in the early 90s, prior to PHP4 even.

No, this is not unique to php. Many popular, comparable languages perform an int -> float conversion. For example, Perl:

$ perl -wle'print "20938410923849012834092834" + 0 if "20938410923849012834092834" == "20938410923849012834092835"'

2.0938410923849e+25

- This is not a philosophical debate about typing styles or the existence of perfect type conversions. PHP's problems in this regard are relics from a dubious past.

Conversion from string -> number, and loose numeric types which auto-convert to float are near universal in loosely typed languages, out of necessity -- if such a scheme doesn't work consistently it can't be used at all. This brings me back to my point. You said "IMO this conversion should fail if the number represented is not valid, or fall back to arbitrary precision math". My response is that you cannot provide such a rule on the basis of "is it valid" because there is no such thing as a "valid" type conversion -- ALL have precision loss. It is inherent in the datatype. When I said "you may be underestimating the difficulty in predicting whether a particular decimal number can be accurately represented as a floating point type" you should perhaps read that as "you cannot do this, it is not possible".

Instead you might suggest that no loose conversion, no loose typing be permitted in a language design -- and I would agree wholeheartedly. But your suggestion that this be handled on a case-by-case basis depending on the numeric value is fundamentally unworkable. Big integers are not the only area this type of problem presents.

You're missing the point -- there is no such thing as a precisely correct conversion to a floating point number.

Your suggestion would make type conversion utterly unusable as it would fail seemingly randomly -- for example on simple numbers such as "0.1"

You just reiterated my point. This is precisely why your original suggestion of failing an "invalid" conversion is untenable. ALL conversions lack precision -- there is no such thing as an "invalid" conversion.

How do you test that it isn't valid? I think you may be underestimating the difficulty in predicting whether a particular decimal number can be accurately represented as a floating point type. It may be non-obvious, but the representation of precise numbers changes depending on the number base. For example, in base 10, we can't precisely represent 1/3. In base 3, we can (0.1). In base 2, we can't precisely represent 0.1, or 1/10. A simple number such as 0.1 has no precise representation in base 2.

In this case in php, the truncation happens due to loss of precision in the mantissa of the double precision float. But there are so many other ways to lose precision, I don't think it's reasonable to ask a language to attempt to account for them.

This is why languages should have clear rules about when type conversion occurs, and allow the user to prevent it when it isn't desirable.

edit: in fact, amusingly, php seems to be doing some non-standard stuff with its floats. I was going to make a point about how you can't determine if a double is a "correct" representation of a string decimal, but in mocking an example I discovered something odd. Check this out:

This is what one should expect:

$ ruby -e'puts "%5.25f" % 0.1'

0.1000000000000000055511151

$ perl -wle'printf "%5.25f\n", 0.1'

0.1000000000000000055511151

But in php:

$ php -r'printf("%5.25f\n", 0.1);'

0.1000000000000000000000000

$ php -r'printf("%5.25f\n", "0.1");'

0.1000000000000000000000000

Is php changing the type conversion? Or not using double precision at all?

This is truer than you know, but for the wrong reasons.

I worked tech support for a shell provider in the 90s and I helped a LOT of users work through the mechanics of setting up a cgi-bin. One of the most difficult concepts for users without a technical background was file permissions -- specifically the execute bit.

I believe PHP's ease of use primarily stems from what most would consider a security vulnerability: mod_php instructs apache to execute code from php files without the execute bit set. This is inherently the same sort of issue behind email worms on Windows -- exec handlers which pass code to an interpreter without honoring the lack of execute permissions.

It's a terrible idea, and also widely popular. I have personally seen users switch from Perl to PHP purely because they could not figure out how to set the execute bit in their Windows FTP program.

The rest is inertia, as far as I'm concerned.