TRUE and FALSE are treated differently

Post removed (X-No-Archive: yes)

Re: TRUE and FALSE are treated differently

In article ,
A Bit Narked wrote:

> Can someone explain the rationale - if there is one - behind
> treating the constants TRUE and FALSE differently?
>
> echo false ;
> echo false+false ;
> echo intval(false) ;
> echo '"'.false.'"' ;
>
> echo true ;
> echo true+true ;
> echo intval(true) ;
> echo '"'.true.'"' ;
>
> should produce
>
> 000"0"121"1"
>
> but instead produces
>
> 00""121"1"
>
> In other words, the only way to output the underlying zero or use
> it in a string is to use 'false+false' or pass it through
> intval(). No such tricks are required to get at the 1 that
> underlies true.
>
> The whole idea of symbolic constants is that they are always
> replaced by the underlying value during translation, and thus
> *anywhere* you would otherwise have to use some obscure "magic
> number" such as 191, you can use a symbolic constant that makes
> sense in your context, such as TOTAL_NATIONS.
>
> Exactly what we get -or php gets- out of php breaking this rule
> was not explained to me by the person who marked my bug report
> 'bogus'. Can someone here explain it?

What I get are the constants/terms/reserved words true and false with
those values. What else do I need? There is no need to know what values
these equate to, if any.

Re: TRUE and FALSE are treated differently

On Sun, 06 Jan 2008 19:26:30 +0100, A Bit Narked
wrote:

> Can someone explain the rationale - if there is one - behind
> treating the constants TRUE and FALSE differently?
>
> echo false ;

Will return nothing (empty string) : ''

> echo false+false ;

Will return 0 (cast to integer): '0';

> echo intval(false) ;

Will return 0 (cast to integer): '00';

> echo '"'.false.'"' ;

Will return '""': '00""';

>
> echo true ;

Will return 1: '00""1';

> echo true+true ;

Will return 2: '00""12';

> echo intval(true) ;

Wil return 1: '00""121';

> echo '"'.true.'"' ;

Will return '"1"': '00""121"1"';

> should produce
>
> 000"0"121"1"

No it shouldn't, echo false will not give you a zero. Take a hard look at
the types section in the manual, especially at type juggling.

--
Rik Wasmus

Re: TRUE and FALSE are treated differently

On Sun, 06 Jan 2008 19:26:30 +0100, A Bit Narked
wrote:
> The whole idea of symbolic constants is that they are always
> replaced by the underlying value during translation, and thus
> *anywhere* you would otherwise have to use some obscure "magic
> number" such as 191, you can use a symbolic constant that makes
> sense in your context, such as TOTAL_NATIONS.

Ah, taking a closer look at your post, I'd say this: you cannot echo true
or false, they have no string value. PHP has loose typing, and false cast
to string would be '', cast to integer would be 0, the fact is that the
underlying value of false is not 0 (yes, it would be in C probably, but
not from the PHP side of things).
--
Rik Wasmus

Re: TRUE and FALSE are treated differently

..oO(A Bit Narked)

>Can someone explain the rationale - if there is one - behind
>treating the constants TRUE and FALSE differently?
>
>echo false ;
>echo false+false ;
>echo intval(false) ;
>echo '"'.false.'"' ;
>
>echo true ;
>echo true+true ;
>echo intval(true) ;
>echo '"'.true.'"' ;
>
>should produce
>
>000"0"121"1"
>
>but instead produces
>
>00""121"1"
>
>In other words, the only way to output the underlying zero or use
>it in a string is to use 'false+false' or pass it through
>intval(). No such tricks are required to get at the 1 that
>underlies true.

First: The internal values of the constants FALSE and TRUE are _not_ the
integers 0 and 1, but the two possible values of the type 'bool':

var_dump(constant('FALSE'));
bool(false)

var_dump(constant('TRUE'));
bool(true)

Second: If you print out a boolean, its value is automatically converted
to a string. How and why this is done is described in the manual:

| A boolean TRUE value is converted to the string "1", the FALSE value
| is represented as "" (empty string). This way you can convert back and
| forth between boolean and string values.

Micha

Re: TRUE and FALSE are treated differently

Post removed (X-No-Archive: yes)

Re: TRUE and FALSE are treated differently

..oO(A Bit Narked)

>On Sun, 06 Jan 2008 19:43:28 +0100,
>"Rik Wasmus" wrote:
>
>>Ah, taking a closer look at your post, I'd say this: you cannot echo true
>>or false, they have no string value. PHP has loose typing, and false cast
>>to string would be '', cast to integer would be 0, the fact is that the
>>underlying value of false is not 0 (yes, it would be in C probably, but
>>not from the PHP side of things).
>
>And yet you can echo true. The output is '1'. You can also
>concat it into a string, where it also becomes a 1. The two
>constants are treated completely differently in that respect.

Nope. Both are just converted to a string:

TRUE => non-empty string ('1', but it could be anything)
FALSE => empty string

Makes perfect sense.

Micha

Re: TRUE and FALSE are treated differently

On Sun, 06 Jan 2008 20:23:15 +0100, Michael Fesser wrot=
e:

> .oO(A Bit Narked)
>
>> On Sun, 06 Jan 2008 19:43:28 +0100,
>> "Rik Wasmus" wrote:
>>
>>> Ah, taking a closer look at your post, I'd say this: you cannot echo=
=

>>> true
>>> or false, they have no string value. PHP has loose typing, and false=
=

>>> cast
>>> to string would be '', cast to integer would be 0, the fact is that =
the
>>> underlying value of false is not 0 (yes, it would be in C probably, =
but
>>> not from the PHP side of things).
>>
>> And yet you can echo true. The output is '1'. You can also
>> concat it into a string, where it also becomes a 1. The two
>> constants are treated completely differently in that respect.
>
> Nope. Both are just converted to a string:
>
> TRUE =3D> non-empty string ('1', but it could be anything)
> FALSE =3D> empty string

AH, for some reason, can't see the previous post Michael comments on, bu=
t =

indeed, echo will convert any variable to string it recieves. That's for=
=

instance how it's possible to define a __toString() method on an object.=

-- =

Rik Wasmus

Re: TRUE and FALSE are treated differently

Post removed (X-No-Archive: yes)

Re: TRUE and FALSE are treated differently

Puzzled wrote:
> On Sun, 06 Jan 2008 19:53:43 +0100,
> Michael Fesser wrote:
>
>>Second: If you print out a boolean, its value is automatically
>>converted to a string. How and why this is done is described in the
>>manual:
>>
>>| A boolean TRUE value is converted to the string "1", the FALSE value
>>| is represented as "" (empty string). This way you can convert back
>>| and forth between boolean and string values.
>
> You don't find that a daft convention? It implies that true has
> an integer value that can undergo autoconversion in a string
> context but false has no value and cannot. I can't find any
> sense in that at all.

So define your own language.

Re: TRUE and FALSE are treated differently

On Sun, 06 Jan 2008 20:38:01 +0100, Puzzled
wrote:

> On Sun, 06 Jan 2008 19:53:43 +0100,
> Michael Fesser wrote:
>
>> Second: If you print out a boolean, its value is automatically converted
>> to a string. How and why this is done is described in the manual:
>>
>> | A boolean TRUE value is converted to the string "1", the FALSE value
>> | is represented as "" (empty string). This way you can convert back and
>> | forth between boolean and string values.
>
> You don't find that a daft convention? It implies that true has
> an integer value that can undergo autoconversion in a string
> context but false has no value and cannot. I can't find any
> sense in that at all.

You assume some things which are just not right, to clarify:
1. An empty string is still as string, the fact that it's empty should not
matter.
2. True doesn't have an 'integer value', it's just that PHP is loosely
typed, with clearly defined casts when converting one into the other.
3. The types of variables PHP has are limited and clearly defined. Don't
assume they're actually something else, a boolean IS a boolean, not just
some mask of an integer, string, or something else.
--
Rik Wasmus

Re: TRUE and FALSE are treated differently

Post removed (X-No-Archive: yes)

Re: TRUE and FALSE are treated differently

On Sun, 06 Jan 2008 23:09:06 +0100, A Bit Narked
wrote:

> Well, thanks to all for your responses. The php developers get
> 2 marks out of 10 for this, in my book. Arbitrary choices should
> fit *with* people's expectations, not go against them.

*your* expectations, not mine.
--
Rik Wasmus

Re: TRUE and FALSE are treated differently

A Bit Narked wrote:

> Well, thanks to all for your responses. The php developers get
> 2 marks out of 10 for this, in my book. Arbitrary choices should
> fit *with* people's expectations, not go against them.

Then prove yourself better than them and write a PHP compiler that fits
people's expectations, whatever those are.


> The whole idea of symbolic constants is that they are always
> replaced by the underlying value during translation

You mean in the lexical analysis. Right. But remember that this is PHP, not
C. When you write the constant "true", it gets replaced by a constant of
boolean type, not a constant of integer type. So, PHP is doing it right.
Sorry to dissapoint you here.


I'm going to say it again, just to make sure there are no misunderstandings:

In PHP, a boolean is different than an integer. Get over it.


(BTW, I'm just curious about what is this book you are following there)

Cheers,
--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

All I know is what the words know, and dead things, and that
makes a handsome little sum, with a beginning and a middle and
an end, as in the well-built phrase and the long sonata of the dead.
-- Samuel Beckett

Re: TRUE and FALSE are treated differently

A Bit Narked wrote:

> And yet you can echo true. The output is '1'.

No -- you can't echo a boolean in PHP. Why you try, the boolean is
implicitly cast to a string.

This:

echo $bool;

is actually executed as if you coded this:

echo (string)$bool;

If you look up the manual on type casting, you'll find that FALSE is cast
to an empty string, and TRUE is cast to a non-empty string.

If you cast to an integer instead of a string, then you'll find that FALSE
is cast to 0, which seems to be what you want.

echo (int)FALSE;

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 7 days, 10:29.]

dhyana.pl/0.3
http://tobyinkster.co.uk/blog/2008/01/06/dhyana/

Re: TRUE and FALSE are treated differently

Post removed (X-No-Archive: yes)

Re: TRUE and FALSE are treated differently

In article ,
A Bit Narked wrote:

> Well, thanks to all for your responses. The php developers get
> 2 marks out of 10 for this, in my book. Arbitrary choices should
> fit *with* people's expectations, not go against them.

Christ on a bicycle, Mr Narked! The PHP reserved words true and false
have values true and false respectively. Can't you get that through your
thick skull? They don't have integer values. Any particular
implementation of PHP can, as far as I am concerned, use whatever values
it likes to represent them internally. I neither know nor care, and I
don't see why you do.

Now push off.

Re: TRUE and FALSE are treated differently

Iván Sánchez Ortega wrote:

> In PHP, a boolean is different than an integer.

PS: if you want to use integer bools in PHP, it's very easy to define them
yourself...

define('_TRUE_', 1);
define('_FALSE_', 0);

echo _FALSE_; // 0
echo _TRUE_; // 1
echo _FALSE_ & _TRUE_; // 0
echo _FALSE_ | _TRUE_; // 1

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 7 days, 12:27.]

New BBC Home Page
http://tobyinkster.co.uk/blog/2008/01/07/bbc-home-page/

Re: TRUE and FALSE are treated differently

Post removed (X-No-Archive: yes)

Re: TRUE and FALSE are treated differently

A Bit Narked wrote:
> On Sun, 6 Jan 2008 23:19:45 +0000,
> Toby A Inkster wrote:
>
>> A Bit Narked wrote:
>>
>>> And yet you can echo true. The output is '1'.
>> No -- you can't echo a boolean in PHP. Why you try, the boolean is
>> implicitly cast to a string.
>>
>> This:
>>
>> echo $bool;
>>
>> is actually executed as if you coded this:
>>
>> echo (string)$bool;
>>
>> If you look up the manual on type casting, you'll find that FALSE is cast
>> to an empty string, and TRUE is cast to a non-empty string.
>>
>> If you cast to an integer instead of a string, then you'll find that FALSE
>> is cast to 0, which seems to be what you want.
>>
>> echo (int)FALSE;
>
> Apologies for imprecise expression :-) PHP provides free
> casting (e.g. to string in echo) so I ignore it.
>
> My real point is that there is no logical relationship between a
> boolean value of TRUE and a string value '1' _except_ where the
> same relationship yields a string value '0' for boolean FALSE.
> I.e., the C precedent.
>
> I'm not fashed by the idea that there's a special boolean type
> whose values are TRUE and FALSE. But logically, the string
> representations of such sui generis values should be 'true' and
> 'false'. There is no logic whatever in string representions of
> '1' and ''. No one has articulated a relationship such that
> '1' and '' makes any sort of sense.
>
> One of the basic principles of good design is predictability.
> 'From one thing know ten thousand things' as the Chinese stated
> it ages ago. So if there's a well-known precedent, we should
> follow it unless we have a powerful reason for not doing ('Ensure
> that everyone after us makes the same mistake we did', as Maurice
> Wilkes put it, to appreciative laughter). And whatever we do
> should be internally consistent. So the calling sequence for
> some new function should be guessable by anyone who knows the
> sequences of similar functions, one value should tell us about
> neighboring values, and so forth.
>
> The PHP developers' choice for the string reps of true and false
> violate this principle all to buggery, which is what got up my
> nostril.
>
> I thought everyone here would immediately see how daft it is, but
> I expect we're circling the drain as a species precisely because
> so many people -even very smart ones- go through life accepting
> without examination that 'whatever is, is right'.
>

Sorry, but it makes perfect sense.

C does not have real boolean values "true" or "false". Rather, it
gimmicks them up by saying anything with a non-zero value is true, and
anything with a zero value is false. One of the problems is that both 1
and 2 are considered true - but in this case true != true (1 != 2).

PHP does have a real boolean "type" with the values "true" and "false".
So true == true all the time.

PHP can also do conversions. Like with C, anything with a non-zero
value is true, and anything with a zero value is false. This includes
an empty string.

And if we kept doing things the same old way, we'd still be rubbing
sticks together to keep the cave warm. Progress always means change.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: TRUE and FALSE are treated differently

Post removed (X-No-Archive: yes)

Re: TRUE and FALSE are treated differently

In article ,
A Bit Narked wrote:

> On Sun, 6 Jan 2008 23:19:45 +0000,
> Toby A Inkster wrote:
>
> >A Bit Narked wrote:
> >
> >> And yet you can echo true. The output is '1'.
> >
> >No -- you can't echo a boolean in PHP. Why you try, the boolean is
> >implicitly cast to a string.
> >
> >This:
> >
> > echo $bool;
> >
> >is actually executed as if you coded this:
> >
> > echo (string)$bool;
> >
> >If you look up the manual on type casting, you'll find that FALSE is cast
> >to an empty string, and TRUE is cast to a non-empty string.
> >
> >If you cast to an integer instead of a string, then you'll find that FALSE
> >is cast to 0, which seems to be what you want.
> >
> > echo (int)FALSE;
>
> Apologies for imprecise expression :-) PHP provides free
> casting (e.g. to string in echo) so I ignore it.
>
> My real point is that there is no logical relationship between a
> boolean value of TRUE and a string value '1' _except_ where the
> same relationship yields a string value '0' for boolean FALSE.
> I.e., the C precedent.

There isn't and there shouldn't be.

> I'm not fashed by the idea that there's a special boolean type
> whose values are TRUE and FALSE. But logically, the string
> representations of such sui generis values should be 'true' and
> 'false'. There is no logic whatever in string representions of
> '1' and ''. No one has articulated a relationship such that
> '1' and '' makes any sort of sense.

What makes more sense is to assert that the result "echo true;" is
undefined.

> One of the basic principles of good design is predictability.
> 'From one thing know ten thousand things' as the Chinese stated
> it ages ago. So if there's a well-known precedent, we should
> follow it unless we have a powerful reason for not doing ('Ensure
> that everyone after us makes the same mistake we did', as Maurice
> Wilkes put it, to appreciative laughter). And whatever we do
> should be internally consistent.

It is internally consistent. I can rely on true and false having those
values respectively. And that's all you need to know. The notion of them
having some "underlying value" is unnecessary.

> The PHP developers' choice for the string reps of true and false
> violate this principle all to buggery, which is what got up my
> nostril.

Nah, it'll be your code that violates things to buggery, as you insist
in your delusion.

> I thought everyone here would immediately see how daft it is, but
> I expect we're circling the drain as a species precisely because
> so many people - even very smart ones - go through life accepting
> without examination that 'whatever is, is right'.

No, we've moved on.

Re: TRUE and FALSE are treated differently

A Bit Narked wrote:
> On Tue, 08 Jan 2008 08:00:23 -0500,
> Jerry Stuckle wrote:
>
>> A Bit Narked wrote:
>>> On Sun, 6 Jan 2008 23:19:45 +0000,
>>> Toby A Inkster wrote:
>>>
>>>> A Bit Narked wrote:
>>>>
>>>>> And yet you can echo true. The output is '1'.
>>>> No -- you can't echo a boolean in PHP. Why you try, the boolean is
>>>> implicitly cast to a string.
>>>>
>>>> This:
>>>>
>>>> echo $bool;
>>>>
>>>> is actually executed as if you coded this:
>>>>
>>>> echo (string)$bool;
>>>>
>>>> If you look up the manual on type casting, you'll find that FALSE is cast
>>>> to an empty string, and TRUE is cast to a non-empty string.
>>>>
>>>> If you cast to an integer instead of a string, then you'll find that FALSE
>>>> is cast to 0, which seems to be what you want.
>>>>
>>>> echo (int)FALSE;
>>> Apologies for imprecise expression :-) PHP provides free
>>> casting (e.g. to string in echo) so I ignore it.
>>>
>>> My real point is that there is no logical relationship between a
>>> boolean value of TRUE and a string value '1' _except_ where the
>>> same relationship yields a string value '0' for boolean FALSE.
>>> I.e., the C precedent.
>>>
>>> I'm not fashed by the idea that there's a special boolean type
>>> whose values are TRUE and FALSE. But logically, the string
>>> representations of such sui generis values should be 'true' and
>>> 'false'. There is no logic whatever in string representions of
>>> '1' and ''. No one has articulated a relationship such that
>>> '1' and '' makes any sort of sense.
>>>
>>> One of the basic principles of good design is predictability.
>>> 'From one thing know ten thousand things' as the Chinese stated
>>> it ages ago. So if there's a well-known precedent, we should
>>> follow it unless we have a powerful reason for not doing ('Ensure
>>> that everyone after us makes the same mistake we did', as Maurice
>>> Wilkes put it, to appreciative laughter). And whatever we do
>>> should be internally consistent. So the calling sequence for
>>> some new function should be guessable by anyone who knows the
>>> sequences of similar functions, one value should tell us about
>>> neighboring values, and so forth.
>>>
>>> The PHP developers' choice for the string reps of true and false
>>> violate this principle all to buggery, which is what got up my
>>> nostril.
>>>
>>> I thought everyone here would immediately see how daft it is, but
>>> I expect we're circling the drain as a species precisely because
>>> so many people -even very smart ones- go through life accepting
>>> without examination that 'whatever is, is right'.
>>>
>> Sorry, but it makes perfect sense.
>>
>> C does not have real boolean values "true" or "false". Rather, it
>> gimmicks them up by saying anything with a non-zero value is true, and
>> anything with a zero value is false. One of the problems is that both 1
>> and 2 are considered true - but in this case true != true (1 != 2).
>>
>> PHP does have a real boolean "type" with the values "true" and "false".
>> So true == true all the time.
>>
>> PHP can also do conversions. Like with C, anything with a non-zero
>> value is true, and anything with a zero value is false. This includes
>> an empty string.
>>
>> And if we kept doing things the same old way, we'd still be rubbing
>> sticks together to keep the cave warm. Progress always means change.
>
> Progress is a type of change, but change is not a type of
> progess.
>
> This seems to be a very easy error to make. You've made it 3
> times in your reply!
>

Not at all. I explained exactly how it works.

If you don't like it, no one is forcing you to use PHP.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: TRUE and FALSE are treated differently

A Bit Narked wrote:

> There is no logic whatever in string representions of '1' and ''.

strlen(TRUE)==TRUE
strlen(FALSE)==FALSE

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 11 days, 22:09.]

NetSol Cybersquatting
http://tobyinkster.co.uk/blog/2008/01/10/netsol-cybersquatti ng/