Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #4592 > unrolled thread

loose thinking

Back to article view | Back to comp.lang.php

Contents

  loose thinking "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-24 11:57 +0100
    Re: loose thinking "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-01-24 14:04 +0100
      Re: loose thinking "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-24 14:32 +0100
        Re: loose thinking The Natural Philosopher <tnp@invalid.invalid> - 2012-01-24 13:41 +0000
          Re: loose thinking Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-24 09:35 -0500
        Re: loose thinking "Peter H. Coffin" <hellsop@ninehells.com> - 2012-01-24 08:16 -0600
          Re: loose thinking "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-24 17:35 +0100
            Re: loose thinking The Natural Philosopher <tnp@invalid.invalid> - 2012-01-24 16:59 +0000
              Re: loose thinking "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-24 19:11 +0100
          Re: loose thinking Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-25 04:49 +0100
            Re: loose thinking "Peter H. Coffin" <hellsop@ninehells.com> - 2012-01-25 07:58 -0600
              Re: loose thinking Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-25 20:37 +0100
        Re: loose thinking "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-01-24 16:20 +0100
          Re: loose thinking The Natural Philosopher <tnp@invalid.invalid> - 2012-01-24 15:43 +0000
          Re: loose thinking "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-24 19:43 +0100
        Re: loose thinking Arno Welzel <usenet@arnowelzel.de> - 2012-01-24 17:02 +0100
          Re: loose thinking "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-24 17:28 +0100

#4592 — loose thinking

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.

[toc] | [next] | [standalone]

#4593

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.syntax.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
--

[toc] | [prev] | [next] | [standalone]

#4594

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.syntax.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.

[toc] | [prev] | [next] | [standalone]

#4595

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.

[toc] | [prev] | [next] | [standalone]

#4597

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#4596

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

[toc] | [prev] | [next] | [standalone]

#4602

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.

[toc] | [prev] | [next] | [standalone]

#4603

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.
> 

[toc] | [prev] | [next] | [standalone]

#4604

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.

[toc] | [prev] | [next] | [standalone]

#4606

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.)

[toc] | [prev] | [next] | [standalone]

#4609

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

[toc] | [prev] | [next] | [standalone]

#4610

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

[toc] | [prev] | [next] | [standalone]

#4598

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
--

[toc] | [prev] | [next] | [standalone]

#4599

Á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.









> 

[toc] | [prev] | [next] | [standalone]

#4605

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.

[toc] | [prev] | [next] | [standalone]

#4600

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.syntax.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

[toc] | [prev] | [next] | [standalone]

#4601

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.syntax.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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web