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

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

switch with case 0

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

Contents

  switch with case 0 Fiver <numeralfive@gmail.com> - 2013-08-17 06:55 +0200
    Re: switch with case 0 "J.O. Aho" <user@example.net> - 2013-08-17 08:35 +0200
      Re: switch with case 0 The Natural Philosopher <tnp@invalid.invalid> - 2013-08-17 08:29 +0100
      Re: switch with case 0 Luuk <luuk@invalid.lan> - 2013-08-17 09:51 +0200
      Re: switch with case 0 Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-08-17 13:16 +0200
        Re: switch with case 0 "Peter H. Coffin" <hellsop@ninehells.com> - 2013-08-17 10:56 -0500
          Re: switch with case 0 The Natural Philosopher <tnp@invalid.invalid> - 2013-08-17 17:45 +0100
            Re: switch with case 0 Tim Streater <timstreater@greenbee.net> - 2013-08-17 18:58 +0100
              Re: switch with case 0 The Natural Philosopher <tnp@invalid.invalid> - 2013-08-17 19:39 +0100
                Re: switch with case 0 Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-08-17 21:36 +0200
          Re: switch with case 0 Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-08-17 22:14 +0200
        Re: switch with case 0 Norman Peelman <npeelman@cfl.rr.com> - 2013-08-17 13:56 -0400
          Re: switch with case 0 Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-08-17 21:55 +0200
            Re: switch with case 0 The Natural Philosopher <tnp@invalid.invalid> - 2013-08-17 21:04 +0100
              Re: switch with case 0 Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-08-17 22:32 +0200
                Re: switch with case 0 Richard Yates <richard@yatesguitar.com> - 2013-08-17 15:20 -0700
              Re: switch with case 0 Fiver <numeralfive@gmail.com> - 2013-08-17 22:37 +0200
                Re: switch with case 0 Norman Peelman <npeelman@cfl.rr.com> - 2013-08-17 19:26 -0400
                Re: switch with case 0 The Natural Philosopher <tnp@invalid.invalid> - 2013-08-18 12:54 +0100
            Re: switch with case 0 Norman Peelman <npeelman@cfl.rr.com> - 2013-08-17 20:23 -0400
              Re: switch with case 0 Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-08-18 15:22 +0200
                Re: switch with case 0 Norman Peelman <npeelman@cfl.rr.com> - 2013-08-18 11:20 -0400
                  Re: switch with case 0 Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-08-18 18:28 +0200
                    Re: switch with case 0 Norman Peelman <npeelman@cfl.rr.com> - 2013-08-18 15:16 -0400
                      Re: switch with case 0 Norman Peelman <npeelman@cfl.rr.com> - 2013-08-18 18:04 -0400
                        Re: switch with case 0 Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-08-19 00:17 +0200
                      Re: switch with case 0 Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-08-19 00:13 +0200
                        Re: switch with case 0 The Natural Philosopher <tnp@invalid.invalid> - 2013-08-19 00:35 +0100
                          Re: switch with case 0 Norman Peelman <npeelman@cfl.rr.com> - 2013-08-19 06:30 -0400
                        Re: switch with case 0 Norman Peelman <npeelman@cfl.rr.com> - 2013-08-18 22:13 -0400
                          Re: switch with case 0 Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-08-19 19:55 +0200
            Re: switch with case 0 Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-19 10:18 +0200
              Re: switch with case 0 Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2013-08-19 19:39 +0200
    Re: switch with case 0 Fiver <numeralfive@gmail.com> - 2013-08-17 16:15 +0200
    Re: switch with case 0 Norman Peelman <npeelman@cfl.rr.com> - 2013-08-17 13:28 -0400

Page 1 of 2  [1] 2  Next page →

#10542 — switch with case 0

This example

  switch ("foo") {
    case 0:
      echo "'foo' is 0\n";
      break;
    default:
      echo "'foo' is not 0\n";
  }

will print: 'foo' is 0.

I know how to avoid the problem, I'm just wondering what kind of
comparison is used that makes "foo" equal to 0? The manual mentions
"loose comparison", but this is even looser than usual.

By the way, the original code was meant to validate SORT_* arguments.
It's a little harder to spot here:

  switch ($mode) {
    case SORT_ASC:
    case SORT_DESC:
    case SORT_REGULAR:
    case SORT_NUMERIC:
    case SORT_STRING:
    case SORT_LOCALE_STRING:
    case SORT_NATURAL:
    case SORT_FLAG_CASE:
      break;
    default:
      throw new \InvalidArgumentException("invalid sort mode: $mode");
  }

SORT_REGULAR is 0, so if the input is a string, this will break (literally).


regards,
5er

[toc] | [next] | [standalone]

#10543

On 17/08/13 06:55, Fiver wrote:
> This example
>
>    switch ("foo") {
>      case 0:
>        echo "'foo' is 0\n";
>        break;
>      default:
>        echo "'foo' is not 0\n";
>    }
>
> will print: 'foo' is 0.

The switch you are doing is equal to a

if("foo" == 0) {}

PHP will make a type casting and try to make the "foo" to a integer, as 
it's not a string only of numeric characters and those it will be cast 
to a 0 which makes your statement true.


You can try this one:

switch("123") {
	case 0:
		echo "it's 0\n";
	  break;

	case 123:
		echo "it's 123\n";
	  break;

	default:
		echo "it's NOT 0 nor 123\n";
}


> I know how to avoid the problem, I'm just wondering what kind of
> comparison is used that makes "foo" equal to 0? The manual mentions
> "loose comparison", but this is even looser than usual.

No it's not looser than normally, PHP don't care so much about data 
types so it internally casts it just to make it easy for those who ain't 
so good at programming.


> By the way, the original code was meant to validate SORT_* arguments.
> It's a little harder to spot here:
>
>    switch ($mode) {
>      case SORT_ASC:
>      case SORT_DESC:
>      case SORT_REGULAR:
>      case SORT_NUMERIC:
>      case SORT_STRING:
>      case SORT_LOCALE_STRING:
>      case SORT_NATURAL:
>      case SORT_FLAG_CASE:
>        break;
>      default:
>        throw new \InvalidArgumentException("invalid sort mode: $mode");
>    }
>
> SORT_REGULAR is 0, so if the input is a string, this will break (literally).

Sounds like you are trusting user input, always validate the user input 
to be a valid value of the type you are requiring. In this case 
is_numeric() could save you from trouble.

-- 

  //Aho

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

#10544

On 17/08/13 07:35, J.O. Aho wrote:
> On 17/08/13 06:55, Fiver wrote:
>
>
>> I know how to avoid the problem, I'm just wondering what kind of
>> comparison is used that makes "foo" equal to 0? The manual mentions
>> "loose comparison", but this is even looser than usual.
>
> No it's not looser than normally, PHP don't care so much about data
> types so it internally casts it just to make it easy for those who
> ain't so good at programming.
>
>  

and bloody nigh impossible for those who are..



-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

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

#10545

On 17-08-2013 08:35, J.O. Aho wrote:
> You can try this one:
>
> switch("123") {
>      case 0:
>          echo "it's 0\n";
>        break;
>
>      case 123:
>          echo "it's 123\n";
>        break;
>
>      default:
>          echo "it's NOT 0 nor 123\n";
> }

or:

You can try this one:

switch("1e3") {
     case 0:
         echo "it's 0\n";
       break;

     case 1000:
         echo "it's 1000\n";
       break;

     default:
         echo "it's NOT 0 nor 1000\n";
}

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

#10546

J.O. Aho schrieb:

> PHP will make a type casting and try to make the "foo" to a integer

And that's precisely what PHP shouldn't do. Cast an integer to a string? 
Yes, no problem, since this can be done without loss of information. But 
the other way round, especially if the string is obviously not 
representing a numeric value? That's just plain stupid.

PHP should never, never, never try to parse out anything from a string 
*unless* explicitly told to do so. And throw an error or return `null` 
in situations like `(int) "foo"`.

> PHP don't care so much about data 
> types so it internally casts it just to make it easy for those who ain't 
> so good at programming.

Easy?!? No it doesn't. On the contrary. A "noob" programmer could write 
a piece of code like the OPs first example (switch ("foo") ... case 0 
...) and rightfully assume it "to work", because in what strange 
parallel universe "foo" could possibly equal 0? Even disregarding the 
fact that they are of different types. "foo" == 0? WTF?!?

>>    switch ($mode) {
>>      case SORT_ASC:
>>      case SORT_DESC:
>>      case SORT_REGULAR:
>>      case SORT_NUMERIC:
>>      case SORT_STRING:
>>      case SORT_LOCALE_STRING:
>>      case SORT_NATURAL:
>>      case SORT_FLAG_CASE:
>>        break;
>>      default:
>>        throw new \InvalidArgumentException("invalid sort mode: $mode");
>>    }

> Sounds like you are trusting user input

No he isn't, as the above code clearly shows. It would work perfectly 
well in any normal programming language (although, personally, I would 
have used in_array() instead of switch).

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

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

#10551

On Sat, 17 Aug 2013 13:16:32 +0200, Thomas Mlynarczyk wrote:
> J.O. Aho schrieb:
>
>> PHP will make a type casting and try to make the "foo" to a integer
>
> And that's precisely what PHP shouldn't do. Cast an integer to a string? 
> Yes, no problem, since this can be done without loss of information. But 
> the other way round, especially if the string is obviously not 
> representing a numeric value? That's just plain stupid.
>
> PHP should never, never, never try to parse out anything from a string 
> *unless* explicitly told to do so. And throw an error or return `null` 
> in situations like `(int) "foo"`.

But the only way to do that that's consistent is to drop "loosely typed"
entirely, and then numeric-to-string goes away as well. And it's NOT "no
problem" either because you need to know how to represent that number.
Is it "0"? "0.0"? "0.00000"? Are big numbers like
"873425783240914325987643256732459087423598876234785624358" or
"8.73425e57"? Are we going with "-4" or "(4)"? And that's before we even
TOUCH on locale issues like whether to use thousands separators, are
they commas, dots, or spaces, and what do decimal places look like? Are
they thousands-sparated as well?  Might as well throw out the one-way
implicit conversion as problematic as well, and just go with a
stronger typing.

Strong-typing introduces its own complications: Are we going to cast
implicitly between numeric types? It's easy to say "Sure, that's okay"
but we're IMMEDIATELY up against float rounding and questions of "Do we
want an explicity DECIMAL type?" and how to compare them. Is "004.50000"
comparable to "4.5000002" and are they equal or not? They're both DECIMAL
types, and differ only precision, and could have been even assigned the
same value in the same statement immediately before like

def	a : decimal(8,5);
def	b : decimal(8,7);

let a = b = 4.5000002; # are we even going to allow this to work, or
		       # should it also fail because we're trying to 
                       # assign a value of a different scope to a 
		       # variable. But we kind of have to allow math
		       # with un-predetermined outcomes to be assigned
                       # to variables, unless we want to explicitly type 
                       # every single term we're going to use...
if (a == b); then
    print "equal\n";
else 
    print "inequal\n";
fi

And then you've got to DOCUMENT all that.

Even just thinking about it makes me 100% behind "We're a loosely-typed
language and it works how it works. If you want to know HOW it's going
to work in a particular case, don't guess, test or look at the source.
Which we make available."

-- 
17. When I employ people as advisors, I will occasionally listen to 
   their advice.
        --Peter Anspach's list of things to do as an Evil Overlord

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

#10552

On 17/08/13 16:56, Peter H. Coffin wrote:
> Strong-typing introduces its own complications: Are we going to cast
> implicitly between numeric types?

No.
>   it makes me 100% behind "We're a loosely-typed language and it works
> how it works. If you want to know HOW it's going to work in a
> particular case, don't guess, test or look at the source. Which we
> make available." 
That is the problem in a nutshell. With a strongly typed language I
don't HAVE to look at the source code. Ther are no implicit rules.There
are only explicit rules and if I say:

float c;

I don't mean char c, char * c; cha** c, char c[]. int c, double c or int
*float(c) ; or anything else.
and I HOPE the compiler will tell me I am being sloppy when I return a 
zero from a function that should return a pointer.

and furthermore if I say case 0: ,  it doesn't mean case '0' or case "0"
or case 0.0 but it can surely mean (because its defined that way)  case
FALSE, and may mean case NULL. but with a few errors thrown up abut
implicit casts.





-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

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

#10560

In article <kuo9bl$4h9$1@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 17/08/13 16:56, Peter H. Coffin wrote:
> > Strong-typing introduces its own complications: Are we going to cast
> > implicitly between numeric types?
> 
> No.
> >   it makes me 100% behind "We're a loosely-typed language and it works
> > how it works. If you want to know HOW it's going to work in a
> > particular case, don't guess, test or look at the source. Which we
> > make available." 
> That is the problem in a nutshell. With a strongly typed language I
> don't HAVE to look at the source code. Ther are no implicit rules.There
> are only explicit rules and if I say:
> 
> float c;
> 
> I don't mean char c, char * c; cha** c, char c[]. int c, double c or int
> *float(c) ; or anything else.
> and I HOPE the compiler will tell me I am being sloppy when I return a 
> zero from a function that should return a pointer.
> 
> and furthermore if I say case 0: ,  it doesn't mean case '0' or case "0"
> or case 0.0 but it can surely mean (because its defined that way)  case
> FALSE, and may mean case NULL. but with a few errors thrown up abut
> implicit casts.

I'd rather not have to bother. And I like to be able to do:


$num = (some calculation here);

if  ($num==0)  $num = "no";

echo "There were " . $num . " widgets\n";


for example.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

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

#10562

On 17/08/13 18:58, Tim Streater wrote:
> In article <kuo9bl$4h9$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> On 17/08/13 16:56, Peter H. Coffin wrote:
>> > Strong-typing introduces its own complications: Are we going to cast
>> > implicitly between numeric types?
>>
>> No.
>> >   it makes me 100% behind "We're a loosely-typed language and it works
>> > how it works. If you want to know HOW it's going to work in a
>> > particular case, don't guess, test or look at the source. Which we
>> > make available." That is the problem in a nutshell. With a strongly
>> typed language I
>> don't HAVE to look at the source code. Ther are no implicit rules.There
>> are only explicit rules and if I say:
>>
>> float c;
>>
>> I don't mean char c, char * c; cha** c, char c[]. int c, double c or int
>> *float(c) ; or anything else.
>> and I HOPE the compiler will tell me I am being sloppy when I return
>> a zero from a function that should return a pointer.
>>
>> and furthermore if I say case 0: ,  it doesn't mean case '0' or case "0"
>> or case 0.0 but it can surely mean (because its defined that way)  case
>> FALSE, and may mean case NULL. but with a few errors thrown up abut
>> implicit casts.
>
> I'd rather not have to bother. And I like to be able to do:
>
>
> $num = (some calculation here);
>
> if  ($num==0)  $num = "no";
>     echo "There were " . $num . " widgets\n"; 
well all you have to do is

char temp[256]; int num;
num = (some calculation here);
printf("There were %s widgets! " num? itoa(num, temp,10): "no");

Shorter than your example.




-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

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

#10564

The Natural Philosopher schrieb:

>> $num = (some calculation here);
>>
>> if  ($num==0)  $num = "no";
>>     echo "There were " . $num . " widgets\n"; 
> well all you have to do is
> 
> char temp[256]; int num;
> num = (some calculation here);
> printf("There were %s widgets! " num? itoa(num, temp,10): "no");
> 
> Shorter than your example.

echo "There were " . ( $num ?: "no" ) . " widgets\n";

But the real problem with this example is: if $num == 1 it should print 
"was" and "widget" instead of "were" and "widgets".

Greetings,
Thomas


-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

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

#10567

Peter H. Coffin schrieb:

[PHP should never implicitly parse out anything from a string]

> But the only way to do that that's consistent is to drop "loosely typed"
> entirely,

No. Why? Other (loosely typed) languages work just fine. Because instead 
of implicitly casting a string to an integer, they rather cast the 
integer to a string. And there's a most natural way to do that: just use 
the syntax for the respective number literal in that language (if 
several different ones are possible, use the shortest representation). 
Thus there are no "locale issues". (For locale specific number 
formatting, there are dedicated functions.)

> Strong-typing introduces its own complications: Are we going to cast
> implicitly between numeric types? It's easy to say "Sure, that's okay"
> but we're IMMEDIATELY up against float rounding and questions of "Do we
> want an explicity DECIMAL type?" and how to compare them.

If the target type is "larger" (wider range of values) and/or "more 
precise" (more decimals) than the source type, there should be no 
problem. The other way round, a (lossless) type conversion may not be 
possible. In that case the language could either throw an exception or 
still perform the conversion with some information loss if reasonably 
acceptable. E.g. if you convert a float(3.14) to int, it's clear that 
the decimals will have to be dropped and the result will be int(3). 
Converting a float larger than PHP_INT_MAX to int could only result in 
PHP_INT_MAX (what else? `null` possibly?). Both are acceptable when done 
*explicitly*. But the language should not perform such lossy conversions 
*implicitly*.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

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

#10559

On 08/17/2013 07:16 AM, Thomas Mlynarczyk wrote:
> J.O. Aho schrieb:
>
>> PHP will make a type casting and try to make the "foo" to a integer
>
> And that's precisely what PHP shouldn't do. Cast an integer to a string?
> Yes, no problem, since this can be done without loss of information. But
> the other way round, especially if the string is obviously not
> representing a numeric value? That's just plain stupid.
>

   That's why it says "foo" = 0. Now is "foo" really 0, no - but it sure 
isn't greater than 0. PHP looks at the string in question one character 
at a time and builds a number until a non-numeric character is reached 
(in a nutshell):

"foo" = 0
"foo2you" = 0
"2fooyou" = 2
"250fooyou" = 250
"250.0fooyou" = 250.0

   The (basic) premise is a string can only result in a number if it 
starts with a number, otherwise not. If you want to know why "foo" = 0 
then, it's the same as doing math with NULL. NULL <> 0 but acts like it 
in computations:

2 * "2fooyou" = 4

> PHP should never, never, never try to parse out anything from a string
> *unless* explicitly told to do so. And throw an error or return `null`
> in situations like `(int) "foo"`.

   An empty string "" = 0, "foo" does not lead with any *numbers* so 
therefor is = 0. Saying (int) "foo" = NULL is like saying "foo" isn't there.

>
>> PHP don't care so much about data types so it internally casts it just
>> to make it easy for those who ain't so good at programming.
>
> Easy?!? No it doesn't. On the contrary. A "noob" programmer could write
> a piece of code like the OPs first example (switch ("foo") ... case 0
> ....) and rightfully assume it "to work", because in what strange
> parallel universe "foo" could possibly equal 0? Even disregarding the
> fact that they are of different types. "foo" == 0? WTF?!?
>
>>>    switch ($mode) {
>>>      case SORT_ASC:
>>>      case SORT_DESC:
>>>      case SORT_REGULAR:
>>>      case SORT_NUMERIC:
>>>      case SORT_STRING:
>>>      case SORT_LOCALE_STRING:
>>>      case SORT_NATURAL:
>>>      case SORT_FLAG_CASE:
>>>        break;
>>>      default:
>>>        throw new \InvalidArgumentException("invalid sort mode: $mode");
>>>    }
>
>> Sounds like you are trusting user input
>
> No he isn't, as the above code clearly shows. It would work perfectly
> well in any normal programming language (although, personally, I would
> have used in_array() instead of switch).
>

   You are assuming $mode is never a string for one. For two, type 
juggling is done at the CASE statement, not the SWITCH statement.


-- 
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-

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

#10565

Norman Peelman schrieb:

>   That's why it says "foo" = 0. Now is "foo" really 0, no - but it sure 
> isn't greater than 0.

In order to compare "foo" and 0 one would need either to convert the 
number 0 to a string ("0" would be the most reasonable result) or 
convert "foo" to a number (not reasonably possible). PHP, unfortunately, 
chooses the unreasonable alternative.

 > PHP looks at the string in question one character
> at a time and builds a number until a non-numeric character is reached 

I am aware of all that. It was decided to make PHP work that way. I was 
merely pointing out that I consider it a very unfortunate decision to 
cast strings to numbers instead of the other way round.

>>>>    switch ($mode) {
>>>>      case SORT_ASC:
>>>>      case SORT_DESC:
>>>>      case SORT_REGULAR:
>>>>      case SORT_NUMERIC:
>>>>      case SORT_STRING:
>>>>      case SORT_LOCALE_STRING:
>>>>      case SORT_NATURAL:
>>>>      case SORT_FLAG_CASE:
>>>>        break;
>>>>      default:
>>>>        throw new \InvalidArgumentException("invalid sort mode: $mode");
>>>>    }
>>
>>> Sounds like you are trusting user input
>>
>> No he isn't, as the above code clearly shows. It would work perfectly
>> well in any normal programming language (although, personally, I would
>> have used in_array() instead of switch).
>>
> 
>   You are assuming $mode is never a string for one.

No I'm not assuming that. If all the SORT_* constants are integers, then 
only the default branch should match in that case. It doesn't in PHP, 
because PHP is made to implicitly convert strings to integers.

> For two, type 
> juggling is done at the CASE statement, not the SWITCH statement.

I am aware of the fact that PHP will try to convert the string into a 
number (even when this would not possibly make any sense). I'm just 
saying that PHP should not have been designed that way.

Greetings,
Thomas


-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

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

#10566

On 17/08/13 20:55, Thomas Mlynarczyk wrote:


>  I'm just saying that PHP should not have been designed that way.
>

sheesh how much time have you GOT???

was PHP ever 'designed' ? It looks to me like a guy in a basement
decided to write an interpreter for active pages, and very time there
was a choice he either did what he felt was most useful, or tossed a coin.

Nobody is forcing you to use it...

..that the way it is...
> Greetings,
> Thomas
>
>


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

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

#10568

The Natural Philosopher schrieb:

> was PHP ever 'designed' ?

Indeed, it was not. It was not intended to be what it is now.

> It looks to me like a guy in a basement
> decided to write an interpreter for active pages, and very time there
> was a choice he either did what he felt was most useful, or tossed a coin.

I'm sure it was well-meant, but then, well-meant is the opposite of well 
done... (or whatever the expression is).

> Nobody is forcing you to use it...

Nobody is forcing you to earn a living ;-) ... But (despite my ranting) 
I actually do enjoy using PHP -- a perfect language might be too boring.

Greetings,
Thomas


-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

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

#10570

On Sat, 17 Aug 2013 22:32:51 +0200, Thomas Mlynarczyk
<thomas@mlynarczyk-webdesign.de> wrote:

>The Natural Philosopher schrieb:
>
>> was PHP ever 'designed' ?
>
>Indeed, it was not. It was not intended to be what it is now.
>
>> It looks to me like a guy in a basement
>> decided to write an interpreter for active pages, and very time there
>> was a choice he either did what he felt was most useful, or tossed a coin.
>
>I'm sure it was well-meant, but then, well-meant is the opposite of well 
>done... (or whatever the expression is).
>
>> Nobody is forcing you to use it...
>
>Nobody is forcing you to earn a living ;-) ... But (despite my ranting) 
>I actually do enjoy using PHP -- a perfect language might be too boring.

I am reminded of the current thread in alt.usage.english about
slippage in the use of the word 'literally'. At least php doesn't
change as you move from one state or year to another.

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

#10569

On 2013-08-17 22:04, The Natural Philosopher wrote:
> On 17/08/13 20:55, Thomas Mlynarczyk wrote:
> 
>>  I'm just saying that PHP should not have been designed that way.
> 
> sheesh how much time have you GOT???
> 
> was PHP ever 'designed' ? It looks to me like a guy in a basement
> decided to write an interpreter for active pages, and very time there
> was a choice he either did what he felt was most useful, or tossed a coin.
> 
> Nobody is forcing you to use it...
> 
> ..that the way it is...

You're right: PHP wasn't designed, it more or less "happened". But just
because we're using an imperfect language doesn't mean we have to shut
up about its weaknesses. Converting strings to integers instead of the
other way around was an unfortunate choice. It's one of the pitfalls
that regularly get people who are more used to other loosely typed
languages (like me in this case).

If you really want to see somebody with "too much time" to complain
about PHP's idiosyncrasies, take a look at http://phpsadness.com/ .
Quite an interesting collection, too, even if not everything on the list
is new or surprising or even wrong.

regards,
5er

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

#10571

On 08/17/2013 04:37 PM, Fiver wrote:
> On 2013-08-17 22:04, The Natural Philosopher wrote:
>> On 17/08/13 20:55, Thomas Mlynarczyk wrote:
>>
>>>   I'm just saying that PHP should not have been designed that way.
>>
>> sheesh how much time have you GOT???
>>
>> was PHP ever 'designed' ? It looks to me like a guy in a basement
>> decided to write an interpreter for active pages, and very time there
>> was a choice he either did what he felt was most useful, or tossed a coin.
>>
>> Nobody is forcing you to use it...
>>
>> ..that the way it is...
>
> You're right: PHP wasn't designed, it more or less "happened". But just
> because we're using an imperfect language doesn't mean we have to shut
> up about its weaknesses. Converting strings to integers instead of the
> other way around was an unfortunate choice. It's one of the pitfalls
> that regularly get people who are more used to other loosely typed
> languages (like me in this case).
>

   The reason it has evolved this way is because you never get integers 
from POST/GET data, you get strings.

> If you really want to see somebody with "too much time" to complain
> about PHP's idiosyncrasies, take a look at http://phpsadness.com/ .
> Quite an interesting collection, too, even if not everything on the list
> is new or surprising or even wrong.
>
> regards,
> 5er
>


-- 
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-

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

#10573

On 17/08/13 21:37, Fiver wrote:
> On 2013-08-17 22:04, The Natural Philosopher wrote:
>> On 17/08/13 20:55, Thomas Mlynarczyk wrote:
>>
>>>  I'm just saying that PHP should not have been designed that way.
>> sheesh how much time have you GOT???
>>
>> was PHP ever 'designed' ? It looks to me like a guy in a basement
>> decided to write an interpreter for active pages, and very time there
>> was a choice he either did what he felt was most useful, or tossed a coin.
>>
>> Nobody is forcing you to use it...
>>
>> ..that the way it is...
> You're right: PHP wasn't designed, it more or less "happened". But just
> because we're using an imperfect language doesn't mean we have to shut
> up about its weaknesses.

OTOH fixing those weaknesses would probably break every single legacy
app out there.

Look at the utter and total MESS that HTML got into with style sheets,
and completely different models in IE versus rest of the world.

you would probably have to do similar..so
<php5

would say ''do this the old buggy way'
and
<php6

or whatever would be 'go to new standard' mode.
but what happens to include files? Aeegghh!!




>  Converting strings to integers instead of the
> other way around was an unfortunate choice. It's one of the pitfalls
> that regularly get people who are more used to other loosely typed
> languages (like me in this case).
>
> If you really want to see somebody with "too much time" to complain
> about PHP's idiosyncrasies, take a look at http://phpsadness.com/ .
> Quite an interesting collection, too, even if not everything on the list
> is new or surprising or even wrong.
well yes.

There were similar religious wars between Intel and Motorola chipsets
when we all coded in assembler. People complaining that intels registers
were quirky and not orthogonal, and all were used in slightly different
ways,. whilst other people claimed that was what made them so useful.

In the end you just learnt what they did, and got on with the job of
writing solid software for them, avoiding all the grey areas completely.



> regards,
> 5er


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

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

#10572

On 08/17/2013 03:55 PM, Thomas Mlynarczyk wrote:
> Norman Peelman schrieb:
>
>>   That's why it says "foo" = 0. Now is "foo" really 0, no - but it
>> sure isn't greater than 0.
>
> In order to compare "foo" and 0 one would need either to convert the
> number 0 to a string ("0" would be the most reasonable result) or
> convert "foo" to a number (not reasonably possible). PHP, unfortunately,
> chooses the unreasonable alternative.
>

   Why is it unreasonable? After all, FORM data is all strings to begin 
with. PHP will type juggle "12345" to 12345 just fine. The whole idea 
behind this after all is not about having strings like "2foo".

>  > PHP looks at the string in question one character
>> at a time and builds a number until a non-numeric character is reached
>
> I am aware of all that. It was decided to make PHP work that way. I was
> merely pointing out that I consider it a very unfortunate decision to
> cast strings to numbers instead of the other way round.
>

FORM data, GET/POST data, all strings...

>>>>>    switch ($mode) {
>>>>>      case SORT_ASC:
>>>>>      case SORT_DESC:
>>>>>      case SORT_REGULAR:
>>>>>      case SORT_NUMERIC:
>>>>>      case SORT_STRING:
>>>>>      case SORT_LOCALE_STRING:
>>>>>      case SORT_NATURAL:
>>>>>      case SORT_FLAG_CASE:
>>>>>        break;
>>>>>      default:
>>>>>        throw new \InvalidArgumentException("invalid sort mode:
>>>>> $mode");
>>>>>    }
>>>
>>>> Sounds like you are trusting user input
>>>
>>> No he isn't, as the above code clearly shows. It would work perfectly
>>> well in any normal programming language (although, personally, I would
>>> have used in_array() instead of switch).
>>>
>>
>>   You are assuming $mode is never a string for one.
>
> No I'm not assuming that. If all the SORT_* constants are integers, then
> only the default branch should match in that case. It doesn't in PHP,
> because PHP is made to implicitly convert strings to integers.
>

   No, the only time the default is reached is when $mode is outside 0-7 
(I say that because i only have 6 of the 8, I haven't updated yet.) If 
$mode = E_ERROR it still validates. This code does nothing to ensure 
$mode is what it is supposed to be.

What about:
-- code --
$mode = setSortMode("SORT_NUMERIC");
echo $mode."\n";

function setSortMode($mode)
{
   switch ($mode)
   {
     case           "SORT_ASC":
     case          "SORT_DESC":
     case       "SORT_REGULAR":
     case       "SORT_NUMERIC":
     case        "SORT_STRING":
     case "SORT_LOCALE_STRING":
     case       "SORT_NATURAL":
     case     "SORT_FLAG_CASE":
                                 return constant($mode);
                                 break;
                       default:
                                 return SORT_REGULAR;
   }
}
-- code --

   Technically speaking, the user should not be able to *choose* an 
invalid mode but if they somehow did, I believe it should default to 
some normal behavior (even if the result isn't what they wanted.) In 
other words, default to SORT_REGULAR (pick your poison) until another 
*valid* option is chosen.

>> For two, type juggling is done at the CASE statement, not the SWITCH
>> statement.
>
> I am aware of the fact that PHP will try to convert the string into a
> number (even when this would not possibly make any sense).

How do you know when it wouldn't make sense?

> I'm just saying that PHP should not have been designed that way.
>

FORMS, GET/POST data = strings...

> Greetings,
> Thomas
>
>


-- 
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web