At 2005-06-06 08:37, Marcus Boerger wrote:
>Sunday, June 5, 2005, 10:27:51 PM, you wrote:
>> On Sun, 5 Jun 2005, Johannes Schlueter wrote:
>>> PHP is a weak-typed language which casts in the background as required - at
>>> least most of the time.
Yes, but I think it doesn't always do it in an
intuitive way and I would rather have errors
or warnings instead.
>>> I recently found an exception which bugged me:
>>>
>>> $a = false;
>>> $a++;
>>>
>>> Here $a isn't casted to int or "incremented" to true but the incrementing
>>> has
>>> no effect. By checking zend_operators.c I saw that booleans had no explicit
>>> incrementing rule but uses just the default in the relevant switch.
Yes, that is strange. I would like to plead for
a real boolean type. The argument of an if or
while statement for example has to be boolean
(or convertable to boolean).
In your case '$a=false;' should give $a the type
and I don't think that integer arithmetic should
be allowed on booleans, because it's confusing and
unnecessary. Give an error or warning instead.
>>> Looking a bit deeper it got quite interesting: NULL++ gives as result the
>>> integer one. This is fine for incrementing undefined variables but imho
>>> inconsistent with the behavior of false. NULL-- evaluates to NULL similar to
>>> false but different from NULL++.
NULL comes from C I think and stands for an uninitialized
pointer. There is no other way to empty a pointer except
by using 'pointer=(*char)0;', using NULL is more clear.
Instead of filling a variable with a null pointer one
can unset() a variable in PHP.
I have no problems with integers and strings being
promoted to booleans, except for example that an
empty string is considered to be false and even
(in some versions?) a string containing '0' or even
'false' or even 'NULL'?
I like to write:
while (fgets($hf)) {
}
But this fails when an empty string is considered to be
false. BTW. the behaviour also depends on the fact if
"\r\n" is considered to be empty or not.
I don't remember if it also happens in the case
above or only in bigger expressions.
>>> All this makes using PHP harder than needed. At least I spent quite some
>>> time
>>> finding that my variable was set to false instead of 0 (or NULL).
My point too. Scripts in overly permissive and
'intelligent' languages like PHP tend to be hard
to debug.
C and Javascript were also made much more strict
later.
BTW. Wouldn't it be a good idea to split this
mailing list in a list about the definition
of the PHP language and the implementation and
versions etc.?
>>> I wrote the attached patch which allows in-/decrementing of simple types by
>>> casting bools and NULL to long. Yes, it would be a BC break but I don't
>>> think
>>> someone relies on false++ being false and it would make life simpler.
>>>
>>> Comments?
>
>> I did this a year or so ago, and after discussing with Andi we decided
>> not to promote types in this case.
As I said above I agree with not auto-promoting
booleans to other types. People should write
'$i=(int)$b;' because this conversion is very
unusual.
>Not promoting types would mean adding false++, and true-- doesn't it?
false is a constant and can't be increment.
When you are in favor of incrementing booleans
you should also be able to increment a veriable
with the value true, but should it become false,
0 or 2 or stay the same?
Of course it's possible to think of the boolean
space as a one bit integer, so true+1 is false
again, but I'd much rather see an error or
warning.
>And again not doing this complicaates php needlessly. For example the two
>snippets below are different, tell me why:
>
>1) if (($p=strpos(...)+1) > 0) ...
>2) $p = strpos(...);
> $p++;
> if ($p > 0) ...
It should be the same indeed.
>Sidenote: Why is the following a parser error:
> if (($p=strpos(...))++ > 0) ...
You can't increment ($p=strpos()), because it's
not a left-value (=assignable variable). This
already wasn't the case in C. The result of an
assignment is the contents of the left-value
and not it's location.
Please also note that in C, the $p++ can lead to
very strange results, because it's not very well
defined when the incrementing is actually done.
For example:
*p++=i++;
shouldn't become:
++i;
*p=i;
++p;
but:
*p=i;
++p;
++i;
or:
*p=i;
++i;
++p;
A C compiler can postpone all of the
auto incrementing until after evaluating the
actual expression, to avoid problems with
expressions like:
*p++=*p++ + *p++;
(which is very dubious otherwise.
Please also consider that in your case:
($p=strpos())++
would have as a result the value of $p after
the assignment from strpos() and not of that
plus on because $p would be increment after
being read. I tend use ++p and ++i wherever
appropriate in C and always in PHP. ++p
always stands for (p+=1) but p++ is much
more dubious.
Greetings,
Jaap
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
