| loose thinking [message #176781] |
Tue, 24 January 2012 10:57  |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
I hate this sloppiness of PHP:
strobel@s114-intel:~> php -a
Interactive shell
php > $a[null] = 'you are Nothing';
php > var_dump($a);
array(1) {
[""]=>
string(15) "you are Nothing"
}
php > $i=null;
php > $a[$i] = 'you are Nothing';
php > var_dump($a);
array(1) {
[""]=>
string(15) "you are Nothing"
}
php > var_dump(key($a));
string(0) ""
There is no difference between an empty string and null in array indexing. That is
stupid. Why does the language not just respect my definitions?
/Str.
|
|
|
|
| Re: loose thinking [message #176782 is a reply to message #176781] |
Tue, 24 January 2012 13:04  |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 24/01/2012 11:57, M. Strobel escribió/wrote:
> I hate this sloppiness of PHP:
>
> strobel@s114-intel:~> php -a
> Interactive shell
>
> php> $a[null] = 'you are Nothing';
> php> var_dump($a);
> array(1) {
> [""]=>
> string(15) "you are Nothing"
> }
> php> $i=null;
> php> $a[$i] = 'you are Nothing';
> php> var_dump($a);
> array(1) {
> [""]=>
> string(15) "you are Nothing"
> }
> php> var_dump(key($a));
> string(0) ""
>
> There is no difference between an empty string and null in array indexing. That is
> stupid. Why does the language not just respect my definitions?
Because your make your definitions fit in something that already have a
previous definition. String keys must be integers or strings, as documented:
http://es.php.net/manual/en/language.types.array.php#language.types.array.s yntax.array-func
It's the same situation where you pass a float to a function that's
defined to expect a string: your param will be cast to the target data type.
As about the array key definition, a key is an identifier so I think
it's reasonable to make it a string.
Having arrays where keys can be any arbitrary data type looks like an
(ahem) interesting idea but you'll have to implement it yourself. If it
can actually be done in pure PHP, the tool is possibly the ArrayIterator
interface:
http://es.php.net/manual/en/class.arrayiterator.php
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: loose thinking [message #176783 is a reply to message #176782] |
Tue, 24 January 2012 13:32 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 24.01.2012 14:04, schrieb "Álvaro G. Vicario":
> El 24/01/2012 11:57, M. Strobel escribió/wrote:
>> I hate this sloppiness of PHP:
>>
>> strobel@s114-intel:~> php -a
>> Interactive shell
>>
>> php> $a[null] = 'you are Nothing';
>> php> var_dump($a);
>> array(1) {
>> [""]=>
>> string(15) "you are Nothing"
>> }
>> php> $i=null;
>> php> $a[$i] = 'you are Nothing';
>> php> var_dump($a);
>> array(1) {
>> [""]=>
>> string(15) "you are Nothing"
>> }
>> php> var_dump(key($a));
>> string(0) ""
>>
>> There is no difference between an empty string and null in array indexing. That is
>> stupid. Why does the language not just respect my definitions?
>
> Because your make your definitions fit in something that already have a previous
> definition. String keys must be integers or strings, as documented:
>
> http://es.php.net/manual/en/language.types.array.php#language.types.array.s yntax.array-func
>
>
> It's the same situation where you pass a float to a function that's defined to expect
> a string: your param will be cast to the target data type.
>
> As about the array key definition, a key is an identifier so I think it's reasonable
> to make it a string.
>
> Having arrays where keys can be any arbitrary data type looks like an (ahem)
> interesting idea but you'll have to implement it yourself. If it can actually be done
> in pure PHP, the tool is possibly the ArrayIterator interface:
>
> http://es.php.net/manual/en/class.arrayiterator.php
>
>
>
Okay I see it is well documented. I just started testing.
I am angry about it because not even isset() respects the null value here. I think it
makes more sense this way: isset($a[null]) should return false, because there is no
null index.
The point is that the designers of PHP (if you can talk about design here) probably
meant to help programmers in not making all these hideous type distinctions, but the
outcome is you have to be really careful about loose comparison and unwanted type
conversion, having to write even more if constructs.
/Str.
|
|
|
|
| Re: loose thinking [message #176784 is a reply to message #176783] |
Tue, 24 January 2012 13:41 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
M. Strobel wrote:
> The point is that the designers of PHP (if you can talk about design here) probably
> meant to help programmers in not making all these hideous type distinctions, but the
> outcome is you have to be really careful about loose comparison and unwanted type
> conversion, having to write even more if constructs.
>
And that in a nutshell is where I feel PHP's greatest weakness lies.
Its the language for the ill educated hacker to pretend (after learning
and mouthing the usual platitudes, a la Stuckle), that he can write good
code in it.
I don't push it too far myself: I tried, but ended up doing the grunt
work in C where I had proper control. PHP just does the presentation
layers. Its good enough for that.
|
|
|
|
| Re: loose thinking [message #176785 is a reply to message #176783] |
Tue, 24 January 2012 14:16 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Tue, 24 Jan 2012 14:32:52 +0100, M. Strobel wrote:
> Okay I see it is well documented. I just started testing.
>
> I am angry about it because not even isset() respects the null value
> here. I think it makes more sense this way: isset($a[null]) should
> return false, because there is no null index.
Parens change precedence. Even on functions.
> The point is that the designers of PHP (if you can talk about design
> here) probably meant to help programmers in not making all these
> hideous type distinctions, but the outcome is you have to be really
> careful about loose comparison and unwanted type conversion, having to
> write even more if constructs.
Yup. If you want Pascal, you know where to find it.
--
A way of life that is odd or even erratic but interferes with no rights
or interests of others is not to be condemned because it is different.
-- Chief Justice Warren E. Burger
|
|
|
|
| Re: loose thinking [message #176786 is a reply to message #176784] |
Tue, 24 January 2012 14:35 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/24/2012 8:41 AM, The Natural Philosopher wrote:
> M. Strobel wrote:
>
>> The point is that the designers of PHP (if you can talk about design
>> here) probably
>> meant to help programmers in not making all these hideous type
>> distinctions, but the
>> outcome is you have to be really careful about loose comparison and
>> unwanted type
>> conversion, having to write even more if constructs.
>>
>
> And that in a nutshell is where I feel PHP's greatest weakness lies.
>
> Its the language for the ill educated hacker to pretend (after learning
> and mouthing the usual platitudes, a la Stuckle), that he can write good
> code in it.
>
> I don't push it too far myself: I tried, but ended up doing the grunt
> work in C where I had proper control. PHP just does the presentation
> layers. Its good enough for that.
>
ROFLMAO! But then that's what I would expect from a ditch digger who
got fired for not knowing which end of the shovel to use.
We already know you aren't a programmer or an engineer like you claim to
be. And now you're "semi-retired" - what happened - lose your
dishwashing job, also?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: loose thinking [message #176787 is a reply to message #176783] |
Tue, 24 January 2012 15:20 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 24/01/2012 14:32, M. Strobel escribió/wrote:
> Okay I see it is well documented. I just started testing.
>
> I am angry about it because not even isset() respects the null value here. I think it
> makes more sense this way: isset($a[null]) should return false, because there is no
> null index.
Whatever implementation details are chosen, they need to be coherent.
I think your proposed behaviour would lead to pretty counter-intuitive
situations:
$foo[NULL] = 33;
if( isset($foo[NULL]) ){
echo $foo[NULL];
}else{
echo '$foo[NULL] is not set'; // Seriously? WTF?
}
> The point is that the designers of PHP (if you can talk about design here) probably
> meant to help programmers in not making all these hideous type distinctions, but the
> outcome is you have to be really careful about loose comparison and unwanted type
> conversion, having to write even more if constructs.
The PHP language has basically evolved along the years as a living
creature would do, unlike other languages that have actually been
designed "on purpose", and it has lots of obvious inconsistencies. But
you are basically suggesting that there's no place for loosely typed
languages and I disagree with that. I'm very happy that I don't need to
write three overloaded versions of the same method just to cope with all
the expected input data types.
Whatever, if you do web stuff and you prefer strong typing I believe you
do have quite a choice, from Java to .NET (VisualBasic and C#). Don't
stick with PHP if you are not going to enjoy its good parts.
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: loose thinking [message #176788 is a reply to message #176787] |
Tue, 24 January 2012 15:43 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Álvaro G. Vicario wrote:
> El 24/01/2012 14:32, M. Strobel escribió/wrote:
>> Okay I see it is well documented. I just started testing.
>>
>> I am angry about it because not even isset() respects the null value
>> here. I think it
>> makes more sense this way: isset($a[null]) should return false,
>> because there is no
>> null index.
>
> Whatever implementation details are chosen, they need to be coherent.
> I think your proposed behaviour would lead to pretty counter-intuitive
> situations:
>
> $foo[NULL] = 33;
> if( isset($foo[NULL]) ){
> echo $foo[NULL];
> }else{
> echo '$foo[NULL] is not set'; // Seriously? WTF?
> }
>
>
>> The point is that the designers of PHP (if you can talk about design
>> here) probably
>> meant to help programmers in not making all these hideous type
>> distinctions, but the
>> outcome is you have to be really careful about loose comparison and
>> unwanted type
>> conversion, having to write even more if constructs.
>
> The PHP language has basically evolved along the years as a living
> creature would do, unlike other languages that have actually been
> designed "on purpose", and it has lots of obvious inconsistencies. But
> you are basically suggesting that there's no place for loosely typed
> languages and I disagree with that. I'm very happy that I don't need to
> write three overloaded versions of the same method just to cope with all
> the expected input data types.
>
well thats the problem with overloading variables in the first place.
More complexity you neither want nor need.
float mtcomp(float x, float y, int z)
is simple, precisely defined within the context of the machine
architecture at least, and will blow up completely one way or another -
and generally at compile time - when fed string representations of
floating point numbers.
> Whatever, if you do web stuff and you prefer strong typing I believe you
> do have quite a choice, from Java to .NET (VisualBasic and C#). Don't
> stick with PHP if you are not going to enjoy its good parts.
>
use C if you must.
Its strongly typed enough and practical enough, and has as many useful
libraries.
Too many people get distracted by OOP BS and typing and generalised
fluff and bollocks to do with languages, that doesn't actually solve the
problem or even help solve the problem, of well specified cleanly
written reasonably clearly documented fast code.
I.e. in the end
OPP loose typing - allows me to be a sloppy programmer when calling it
and makes me have to deal with the problems when writing it of all the
sloppiness I might conceivably throw at any given object.
Loosely typed procedural is great because I can be sloppy when writing
the functions and in calling them, but it will blow up in strange ways I
didn't anticipate when it decides to do something I didn't anticipate
either.
Strictly typed procedural means it does what it says on the tin, no more
and no less, but I have to decide what that is first. And any
sloppiness the compiler will throw in my face, or it will segfault when
run.
Frankly I prefer the latter. For anything of serious complexity anyway.
OOP is OK, but only where its definitely a shorter method to the desired
solution.
>
|
|
|
|
| Re: loose thinking [message #176789 is a reply to message #176783] |
Tue, 24 January 2012 16:02 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
M. Strobel, 2012-01-24 14:32:
> Am 24.01.2012 14:04, schrieb "Álvaro G. Vicario":
>> El 24/01/2012 11:57, M. Strobel escribió/wrote:
>>> I hate this sloppiness of PHP:
[...]
>>> There is no difference between an empty string and null in array indexing. That is
>>> stupid. Why does the language not just respect my definitions?
>>
>> Because your make your definitions fit in something that already have a previous
>> definition. String keys must be integers or strings, as documented:
>>
>> http://es.php.net/manual/en/language.types.array.php#language.types.array.s yntax.array-func
[...]
> I am angry about it because not even isset() respects the null value here. I think it
> makes more sense this way: isset($a[null]) should return false, because there is no
> null index.
>
> The point is that the designers of PHP (if you can talk about design here) probably
> meant to help programmers in not making all these hideous type distinctions, but the
> outcome is you have to be really careful about loose comparison and unwanted type
> conversion, having to write even more if constructs.
Well - the roots of PHP are PHP/FI which could not be called a
"designed" language.
See <http://www.php.net/manual/phpfi2.php#history>
*scnr*
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: loose thinking [message #176790 is a reply to message #176789] |
Tue, 24 January 2012 16:28 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 24.01.2012 17:02, schrieb Arno Welzel:
> M. Strobel, 2012-01-24 14:32:
>
>> Am 24.01.2012 14:04, schrieb "Álvaro G. Vicario":
>>> El 24/01/2012 11:57, M. Strobel escribió/wrote:
>>>> I hate this sloppiness of PHP:
> [...]
>>>> There is no difference between an empty string and null in array indexing. That is
>>>> stupid. Why does the language not just respect my definitions?
>>>
>>> Because your make your definitions fit in something that already have a previous
>>> definition. String keys must be integers or strings, as documented:
>>>
>>> http://es.php.net/manual/en/language.types.array.php#language.types.array.s yntax.array-func
> [...]
>> I am angry about it because not even isset() respects the null value here. I think it
>> makes more sense this way: isset($a[null]) should return false, because there is no
>> null index.
>>
>> The point is that the designers of PHP (if you can talk about design here) probably
>> meant to help programmers in not making all these hideous type distinctions, but the
>> outcome is you have to be really careful about loose comparison and unwanted type
>> conversion, having to write even more if constructs.
>
> Well - the roots of PHP are PHP/FI which could not be called a
> "designed" language.
>
> See <http://www.php.net/manual/phpfi2.php#history>
>
> *scnr*
>
I did not want to be too harsh here. When I started with PHP I wondered why I had to
put the dollar sign on every variable, the language designers did not know the
difference between a variable and a value. Than I had to rename all my .php3
scripts to .php4 and got used to it.
/Str.
|
|
|
|
| Re: loose thinking [message #176791 is a reply to message #176785] |
Tue, 24 January 2012 16:35 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 24.01.2012 15:16, schrieb Peter H. Coffin:
> On Tue, 24 Jan 2012 14:32:52 +0100, M. Strobel wrote:
>
>> Okay I see it is well documented. I just started testing.
>>
>> I am angry about it because not even isset() respects the null value
>> here. I think it makes more sense this way: isset($a[null]) should
>> return false, because there is no null index.
>
> Parens change precedence. Even on functions.
>
>> The point is that the designers of PHP (if you can talk about design
>> here) probably meant to help programmers in not making all these
>> hideous type distinctions, but the outcome is you have to be really
>> careful about loose comparison and unwanted type conversion, having to
>> write even more if constructs.
>
> Yup. If you want Pascal, you know where to find it.
In my library, Niklaus Wirth, Algorithms and Data Structures, 3. Ed. 1983.
But not so much in web programming.
/Str.
|
|
|
|
| Re: loose thinking [message #176792 is a reply to message #176791] |
Tue, 24 January 2012 16:59 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
M. Strobel wrote:
> Am 24.01.2012 15:16, schrieb Peter H. Coffin:
>> On Tue, 24 Jan 2012 14:32:52 +0100, M. Strobel wrote:
>>
>>> Okay I see it is well documented. I just started testing.
>>>
>>> I am angry about it because not even isset() respects the null value
>>> here. I think it makes more sense this way: isset($a[null]) should
>>> return false, because there is no null index.
>> Parens change precedence. Even on functions.
>>
>>> The point is that the designers of PHP (if you can talk about design
>>> here) probably meant to help programmers in not making all these
>>> hideous type distinctions, but the outcome is you have to be really
>>> careful about loose comparison and unwanted type conversion, having to
>>> write even more if constructs.
>> Yup. If you want Pascal, you know where to find it.
>
> In my library, Niklaus Wirth, Algorithms and Data Structures, 3. Ed. 1983.
>
> But not so much in web programming.
>
Indeed. So strongly typed as to be almost unusable in the real world.
At least C gave you the cast and the union.
YOU try writing a disk access program in Pascal, where the sector coming
off the disk might be a file or directory structure with a specific
layout, or a simple block of binary data.
I gave up and rewrote the sodding thing in C..
> /Str.
>
|
|
|
|
| Re: loose thinking [message #176793 is a reply to message #176792] |
Tue, 24 January 2012 18:11 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 24.01.2012 17:59, schrieb The Natural Philosopher:
> M. Strobel wrote:
>> Am 24.01.2012 15:16, schrieb Peter H. Coffin:
>>> On Tue, 24 Jan 2012 14:32:52 +0100, M. Strobel wrote:
>>>
>>>> Okay I see it is well documented. I just started testing.
>>>>
>>>> I am angry about it because not even isset() respects the null value
>>>> here. I think it makes more sense this way: isset($a[null]) should
>>>> return false, because there is no null index.
>>> Parens change precedence. Even on functions.
>>>
>>>> The point is that the designers of PHP (if you can talk about design
>>>> here) probably meant to help programmers in not making all these
>>>> hideous type distinctions, but the outcome is you have to be really
>>>> careful about loose comparison and unwanted type conversion, having to
>>>> write even more if constructs.
>>> Yup. If you want Pascal, you know where to find it.
>>
>> In my library, Niklaus Wirth, Algorithms and Data Structures, 3. Ed. 1983.
>>
>> But not so much in web programming.
>>
> Indeed. So strongly typed as to be almost unusable in the real world.
>
> At least C gave you the cast and the union.
>
> YOU try writing a disk access program in Pascal, where the sector coming off the disk
> might be a file or directory structure with a specific layout, or a simple block of
> binary data.
>
> I gave up and rewrote the sodding thing in C..
>
I don't agree to 'almost unusable'. It's a little OT, but...
Pascal was designed as a problem solver, not a system programming language. And it
was well accepted for speed and program clarity, until Delphi came out and people did
not know it was Pascal, and the move to Modula-2 divided the community more.
It left a gap as business logic solver, until Java tried to fill it. Not to talk
about baby babble COBOL.
/Str.
|
|
|
|
| Re: loose thinking [message #176794 is a reply to message #176787] |
Tue, 24 January 2012 18:43 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 24.01.2012 16:20, schrieb "Álvaro G. Vicario":
> El 24/01/2012 14:32, M. Strobel escribió/wrote:
>> Okay I see it is well documented. I just started testing.
>>
>> I am angry about it because not even isset() respects the null value here. I think it
>> makes more sense this way: isset($a[null]) should return false, because there is no
>> null index.
>
> Whatever implementation details are chosen, they need to be coherent.
> I think your proposed behaviour would lead to pretty counter-intuitive situations:
>
> $foo[NULL] = 33;
> if( isset($foo[NULL]) ){
> echo $foo[NULL];
> }else{
> echo '$foo[NULL] is not set'; // Seriously? WTF?
> }
>
>
>> The point is that the designers of PHP (if you can talk about design here) probably
>> meant to help programmers in not making all these hideous type distinctions, but the
>> outcome is you have to be really careful about loose comparison and unwanted type
>> conversion, having to write even more if constructs.
>
> The PHP language has basically evolved along the years as a living creature would do,
> unlike other languages that have actually been designed "on purpose", and it has lots
> of obvious inconsistencies. But you are basically suggesting that there's no place
> for loosely typed languages and I disagree with that. I'm very happy that I don't
> need to write three overloaded versions of the same method just to cope with all the
> expected input data types.
>
> Whatever, if you do web stuff and you prefer strong typing I believe you do have
> quite a choice, from Java to .NET (VisualBasic and C#). Don't stick with PHP if you
> are not going to enjoy its good parts.
>
Enjoy the good parts, but can't avoid the bad parts. Some public wailing will warn
the lurkers.
The Windows stuff is not portable, and system complexity far above unix. Maybe not if
you just click. Programmers don't just click.
/Str.
|
|
|
|
| Re: loose thinking [message #176795 is a reply to message #176785] |
Wed, 25 January 2012 03:49 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Peter H. Coffin wrote:
> On Tue, 24 Jan 2012 14:32:52 +0100, M. Strobel wrote:
>> Okay I see it is well documented. I just started testing.
>>
>> I am angry about it because not even isset() respects the null value
>> here. I think it makes more sense this way: isset($a[null]) should
>> return false, because there is no null index.
>
> Parens change precedence. Even on functions.
You are missing the point, which is: `null' is being converted to the
primitive string value ''. A key of an *associative* array may be the empty
string. And that is good so.
What is questionable here is the implicit type conversion of non-numeric
values to string. But PHP is not alone there, so this behavior can be
expected. It might be nice if E_STRICT reported such spurious conversions
or there was an even stricter mode that forbade them. Perhaps in PHP 6 …
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
|
|
|
|
| Re: loose thinking [message #176797 is a reply to message #176795] |
Wed, 25 January 2012 13:58 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Wed, 25 Jan 2012 04:49:19 +0100, Thomas 'PointedEars' Lahn wrote:
> Peter H. Coffin wrote:
>
>> On Tue, 24 Jan 2012 14:32:52 +0100, M. Strobel wrote:
>>> Okay I see it is well documented. I just started testing.
>>>
>>> I am angry about it because not even isset() respects the null value
>>> here. I think it makes more sense this way: isset($a[null]) should
>>> return false, because there is no null index.
>>
>> Parens change precedence. Even on functions.
>
> You are missing the point, which is: `null' is being converted to the
> primitive string value ''. A key of an *associative* array may be the empty
> string. And that is good so.
That's the *same point*, not "missing the point". I'm sorry that I'm not
wandering down the same mental path would, but I don't think in exactly
the same terms you do. Not everybody does.
> What is questionable here is the implicit type conversion of non-numeric
> values to string. But PHP is not alone there, so this behavior can be
> expected. It might be nice if E_STRICT reported such spurious conversions
> or there was an even stricter mode that forbade them. Perhaps in PHP 6 ???
null's a special case that's NOT reported. Other cases of this are
reported.
hellsop /home/hellsop
[07:57:10] $ cat foo.php
<?php
$arr = array( q => 'r');
print_r($arr);
?>
hellsop /home/hellsop
[07:57:12] $ php -f foo.php
PHP Notice: Use of undefined constant q - assumed 'q' in
/home/hellsop/foo.php on line 3
Array
(
[q] => r
)
hellsop /home/hellsop
[07:57:15] $
--
32. I will not fly into a rage and kill a messenger who brings me bad
news just to illustrate how evil I really am. Good messengers are
hard to come by.
--Peter Anspach's list of things to do as an Evil Overlord
|
|
|
|
| Re: loose thinking [message #176798 is a reply to message #176797] |
Wed, 25 January 2012 19:37 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Peter H. Coffin wrote:
> On Wed, 25 Jan 2012 04:49:19 +0100, Thomas 'PointedEars' Lahn wrote:
>> Peter H. Coffin wrote:
>>> On Tue, 24 Jan 2012 14:32:52 +0100, M. Strobel wrote:
>>>> Okay I see it is well documented. I just started testing.
>>>>
>>>> I am angry about it because not even isset() respects the null value
>>>> here. I think it makes more sense this way: isset($a[null]) should
>>>> return false, because there is no null index.
>>> Parens change precedence. Even on functions.
>>
>> You are missing the point, which is: `null' is being converted to the
>> primitive string value ''. A key of an *associative* array may be the
>> empty string. And that is good so.
>
> That's the *same point*, not "missing the point". I'm sorry that I'm not
> wandering down the same mental path would, but I don't think in exactly
> the same terms you do. Not everybody does.
I do not follow. Please explain why you think (operator) precedence has
something to do with this problem.
>> What is questionable here is the implicit type conversion of non-numeric
>> values to string. But PHP is not alone there, so this behavior can be
>> expected. It might be nice if E_STRICT reported such spurious
>> conversions
>> or there was an even stricter mode that forbade them. Perhaps in PHP 6
>> ???
There were no question marks in my posting, there was an ellipsis. Please
get a working newsreader; Unicode and UTF-8 are anything but new or exotic
nowadays.
> null's a special case that's NOT reported. Other cases of this are
> reported.
>
> hellsop /home/hellsop
> [07:57:10] $ cat foo.php
> <?php
>
> $arr = array( q => 'r');
>
> print_r($arr);
>
> ?>
> hellsop /home/hellsop
> [07:57:12] $ php -f foo.php
> PHP Notice: Use of undefined constant q - assumed 'q' in
> /home/hellsop/foo.php on line 3
Please notice that this is only a notice.
> Array
> (
> [q] => r
> )
> hellsop /home/hellsop
> [07:57:15] $
Because `null' is a reserved word, thus cannot be the identifier of a
constant. Where `null' is the value of another expression (like a variable
reference), PHP shows its being influenced by C, Perl and Tcl, and its
applicability as a shell scripting language, where (with the exception of C)
loose typing is common and you do not have to declare variables before you
refer to them.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]