I read an argument about the 'bit' type.  It seems people can do this:

int i = true * 8; // yields 8
i = false * 8; // yields 0 ?

Static operators or methods eliminate this problem!  Get rid of the 'true' and 'false' keywords!!

I propose:

bit a;
bit.settrue(a);
bit b;
bit.setfalse(b);
a = b || !b;

There are probably better names for these 2 methods...  'setto1' and 'setto0'? Doing so eliminates the need for 'true' and 'false' keywords!

I would like to see the following keywords ELIMINATED, as they are just a source for exceptions:

null
false
true

Sam-
sam987883@yahoo.com

If that happened, I would add this to all my fales:

const int true = 1;
const int false = 0;
const void* null = cast(void*) 0;

Remember - bit and bool are the same type.  You're asking me to change this:

bool test()
{
   return true;
}

To this:

bool test()
{
   bool tempvar;
   tempvar.setto1();
   return tempvar;
}

You're smoking something strong.  Modern languages (e.g. C++, C#, PHP, JavaScript, etc.) all have concepts of true and false.

-[Unknown]


> I read an argument about the 'bit' type.  It seems people can do this:
> 
> int i = true * 8; // yields 8
> i = false * 8; // yields 0 ?
> 
> Static operators or methods eliminate this problem!  Get rid of the 'true' and
> 'false' keywords!!
> 
> I propose:
> 
> bit a;
> bit.settrue(a);
> bit b;
> bit.setfalse(b);
> a = b || !b;
> 
> There are probably better names for these 2 methods...  'setto1' and 'setto0'?
> Doing so eliminates the need for 'true' and 'false' keywords!

In article <d751eu$2r8p$1@digitaldaemon.com>, Sam says...
>
>I propose:
>
>bit a;
>bit.settrue(a);
>bit b;
>bit.setfalse(b);
>a = b || !b;
>
> [...]
>I would like to see the following keywords ELIMINATED, as they are just a
> source for exceptions:
>
>null
>false
>true

You really like setter functions and hate keywords don't you ;-) But I honestly can't say I understand why the current syntax (with keywords) is a problem.

Nick

In that case, you could do:

bool test()
{
return 1; // (bool) 1
}

'true' and 'false' are specific interpretations of 'bool' or 'bit', not applicable to all situations!  'on' or 'off', 'enabled' or 'disabled', etc.

So it should be up to the developer to always define their own constants:

const int true = 1;
const int false = 0;
const int on = 1;
const int off = 0;
const int enabled = 1;
const int disabled = 0;

See?

If you don't like my 'truthify' and 'falsify' methods, then let's stick to 0 or 1 and the = operator.

In article <d7528c$2rpn$1@digitaldaemon.com>, Unknown W. Brackets says...
>
>If that happened, I would add this to all my fales:
>
>const int true = 1;
>const int false = 0;
>const void* null = cast(void*) 0;
>
>Remember - bit and bool are the same type.  You're asking me to change this:
>
>bool test()
>{
>    return true;
>}
>
>To this:
>
>bool test()
>{
>    bool tempvar;
>    tempvar.setto1();
>    return tempvar;
>}
>
>You're smoking something strong.  Modern languages (e.g. C++, C#, PHP, JavaScript, etc.) all have concepts of true and false.
>
>-[Unknown]
>
>
>> I read an argument about the 'bit' type.  It seems people can do this:
>> 
>> int i = true * 8; // yields 8
>> i = false * 8; // yields 0 ?
>> 
>> Static operators or methods eliminate this problem!  Get rid of the 'true' and 'false' keywords!!
>> 
>> I propose:
>> 
>> bit a;
>> bit.settrue(a);
>> bit b;
>> bit.setfalse(b);
>> a = b || !b;
>> 
>> There are probably better names for these 2 methods...  'setto1' and 'setto0'? Doing so eliminates the need for 'true' and 'false' keywords!

I could see an argument for making true and false distinct from integer types. This is what C# has done. As a .NET expert, do you think that this was a bad choice in C#?

But getting rid of true and false altogether....I don't know about that. Why do you say they cause exceptions?

Jim


"Sam" <Sam_member@pathlink.com> wrote in message news:d751eu$2r8p$1@digitaldaemon.com...
>
> I read an argument about the 'bit' type.  It seems people can do this:
>
> int i = true * 8; // yields 8
> i = false * 8; // yields 0 ?
>
> Static operators or methods eliminate this problem!  Get rid of the 'true'
> and
> 'false' keywords!!
>
> I propose:
>
> bit a;
> bit.settrue(a);
> bit b;
> bit.setfalse(b);
> a = b || !b;
>
> There are probably better names for these 2 methods...  'setto1' and
> 'setto0'?
> Doing so eliminates the need for 'true' and 'false' keywords!
>
> I would like to see the following keywords ELIMINATED, as they are just a
> source
> for exceptions:
>
> null
> false
> true
>
> Sam-
> sam987883@yahoo.com

I think it's a mistake in C# and ANY LANGUAGE that have kept 'true' and 'false'!

I don't mean to sound like a Boolean extremist, but how often do these 2 keywords get used??  Honestly????

Basically, true and false have only 2 functions, and you only ever need only one of them!!!  Because false = !true

One function is testing a value:

if(b == true)

BUT, you can just do this:

if(b)

Second is assignment:

b = true;
b = !true;

BUT, you can do this instead:

b = 1;
b = 0;

1 and 0 are already part of almost every programming language!

Why keep keywords that are not needed?


In C++ we didn't have a 'null' keyword, and we never needed one!

The less keywords a language has, the simpler it bacomes and the easier it is to learn.

Exceptions from true and false??  Maybe!  What does this do:

cout << true << false; // ?

In article <d756vq$307c$1@digitaldaemon.com>, Jim H says...
>
>
>I could see an argument for making true and false distinct from integer types. This is what C# has done. As a .NET expert, do you think that this was a bad choice in C#?
>
>But getting rid of true and false altogether....I don't know about that. Why do you say they cause exceptions?
>
>Jim
>
>
>"Sam" <Sam_member@pathlink.com> wrote in message news:d751eu$2r8p$1@digitaldaemon.com...
>>
>> I read an argument about the 'bit' type.  It seems people can do this:
>>
>> int i = true * 8; // yields 8
>> i = false * 8; // yields 0 ?
>>
>> Static operators or methods eliminate this problem!  Get rid of the 'true'
>> and
>> 'false' keywords!!
>>
>> I propose:
>>
>> bit a;
>> bit.settrue(a);
>> bit b;
>> bit.setfalse(b);
>> a = b || !b;
>>
>> There are probably better names for these 2 methods...  'setto1' and
>> 'setto0'?
>> Doing so eliminates the need for 'true' and 'false' keywords!
>>
>> I would like to see the following keywords ELIMINATED, as they are just a
>> source
>> for exceptions:
>>
>> null
>> false
>> true
>>
>> Sam-
>> sam987883@yahoo.com
>
>

On Thu, 26 May 2005 20:23:16 +0000 (UTC), Sam wrote:

> I think it's a mistake in C# and ANY LANGUAGE that have kept 'true' and 'false'!
> 
> I don't mean to sound like a Boolean extremist, but how often do these 2 keywords get used??  Honestly????

In my Build utility I use these key words 185 times.

> Basically, true and false have only 2 functions, and you only ever need only one of them!!!  Because false = !true

So let's also write all numeric literals in binary too, 'cos we only need
ones and zeros to do that.

> One function is testing a value:
> 
> if(b == true)
> 
> BUT, you can just do this:
> 
> if(b)
> 
> Second is assignment:
> 
> b = true;
> b = !true;
> 
> BUT, you can do this instead:
> 
> b = 1;
> b = 0;
> 
> 1 and 0 are already part of almost every programming language!
> 
> Why keep keywords that are not needed?

To make code easier for people to read. A programming language's main purpose is to help people to express algorithms in a cost-effective manner. To be able to easily write and read programming code is paramount.

> In C++ we didn't have a 'null' keyword, and we never needed one!
> 
> The less keywords a language has, the simpler it bacomes and the easier it is to learn.

Have you ever had a good look at Forth? Now that is a language with a small (read: non-existent) set of keywords.

-- 
Derek Parnell
Melbourne, Australia
27/05/2005 6:26:51 AM

Well, Sam, I think you have used up your allotment of exclamation points for the whole week!! :-)


"Sam" <Sam_member@pathlink.com> wrote in message news:d75b7k$2a6$1@digitaldaemon.com...
>
>
> BUT, you can just do this:
>
> if(b)
>

But what does this really mean? If 'b' is what?

The if statement works on a boolean expression. The implied meaning is "if b != 0". And that meaning is built into the language and you have to know that. Boolean false is 0 and boolean true is anything not 0. At least in C that's the case. (But in some other language maybe not.)

So as Mr Brackets pointed out, people will start to define "true" and "false" in their code all the time. As in:

  const int true = 1;
  const int false = 0;

or perhaps...

   enum bool {false, true}

It can help to add something to the language that everyone uses a lot anyway; see the rationale for builtins in D.

A problem is that one person will define "true=1", someone else will define "TRUE=1", and a third person will define "True=1". It gets confusing.

One thing that popped into mind is: what if I meant to type:

if(b == 42)        // evaluates to a boolean
{}

but I accidentally typed:

if(b = 42)         // evaluates to an integer
{}

I'm sure there are better examples but that's all I can think of at the moment.

> Second is assignment:
>
> b = true;
> b = !true;
>
> BUT, you can do this instead:
>
> b = 1;
> b = 0;
>
> 1 and 0 are already part of almost every programming language!
>
> Why keep keywords that are not needed?
>
>

It may be _possible_ to do that. But to me, "true" is conceptually a different thing than "1". And I think it's clearer if the code reflects that difference. A boolean is more like an enumeration that has two values, true and false, and cannot be set to anything else.

> In C++ we didn't have a 'null' keyword, and we never needed one!
>
> The less keywords a language has, the simpler it bacomes and the easier it
> is to
> learn.

But EVERYONE always defines NULL = 0 anyway. And then there's all that casting since 0 isn't really a pointer type.

>
> Exceptions from true and false??  Maybe!  What does this do:
>
> cout << true << false; // ?
>

On Microsoft C++ it outputs a 1 and then a 0. I don't know about any other implementations or languages.

Jim

Yeah, you're probably right!  Yeah, I do use too many exclamation points! Elaine from Seinfeld would not be pleased!

I like you argument of people always defining their own constants, and making it part of the language keeps them consistent.

I got burned once a looooooooooong time ago...   In a company far, far away...

It was the end of the Clinton era, and the job market was booming...

I did something like:

std::cout << true;

Except it wasn't with STL...  I don't remember if it was with VB6, MFC or java, but one of those languages screwed me my outputing to a file the string "true" and "false", INSTEAD of 1 or 0.

Like most people I never test my code (that's extra time I could be using to write more code or surfing the web) and I got burned!  Bad!!

Wish I could remember which language this was in...


In article <d75h5o$7f3$1@digitaldaemon.com>, Jim H says...
>
>
>Well, Sam, I think you have used up your allotment of exclamation points for the whole week!! :-)
>
>
>"Sam" <Sam_member@pathlink.com> wrote in message news:d75b7k$2a6$1@digitaldaemon.com...
>>
>>
>> BUT, you can just do this:
>>
>> if(b)
>>
>
>But what does this really mean? If 'b' is what?
>
>The if statement works on a boolean expression. The implied meaning is "if b != 0". And that meaning is built into the language and you have to know that. Boolean false is 0 and boolean true is anything not 0. At least in C that's the case. (But in some other language maybe not.)
>
>So as Mr Brackets pointed out, people will start to define "true" and "false" in their code all the time. As in:
>
>  const int true = 1;
>  const int false = 0;
>
>or perhaps...
>
>   enum bool {false, true}
>
>It can help to add something to the language that everyone uses a lot anyway; see the rationale for builtins in D.
>
>A problem is that one person will define "true=1", someone else will define "TRUE=1", and a third person will define "True=1". It gets confusing.
>
>One thing that popped into mind is: what if I meant to type:
>
>if(b == 42)        // evaluates to a boolean
>{}
>
>but I accidentally typed:
>
>if(b = 42)         // evaluates to an integer
>{}
>
>I'm sure there are better examples but that's all I can think of at the moment.
>
>> Second is assignment:
>>
>> b = true;
>> b = !true;
>>
>> BUT, you can do this instead:
>>
>> b = 1;
>> b = 0;
>>
>> 1 and 0 are already part of almost every programming language!
>>
>> Why keep keywords that are not needed?
>>
>>
>
>It may be _possible_ to do that. But to me, "true" is conceptually a different thing than "1". And I think it's clearer if the code reflects that difference. A boolean is more like an enumeration that has two values, true and false, and cannot be set to anything else.
>
>> In C++ we didn't have a 'null' keyword, and we never needed one!
>>
>> The less keywords a language has, the simpler it bacomes and the easier it
>> is to
>> learn.
>
>But EVERYONE always defines NULL = 0 anyway. And then there's all that casting since 0 isn't really a pointer type.
>
>>
>> Exceptions from true and false??  Maybe!  What does this do:
>>
>> cout << true << false; // ?
>>
>
>On Microsoft C++ it outputs a 1 and then a 0. I don't know about any other implementations or languages.
>
>Jim
>
>

"Sam" <Sam_member@pathlink.com> wrote in message news:d75itd$8nt$1@digitaldaemon.com...
> Except it wasn't with STL...  I don't remember if it was with VB6, MFC or
> java,
> but one of those languages screwed me my outputing to a file the string
> "true"
> and "false", INSTEAD of 1 or 0.
> Wish I could remember which language this was in...

MFC is not a language, and std::cout << true; is quite obviously C++ code..

> Like most people I never test my code

You mean _unlike_ most people?

Something tells me you're not a programmer by trade.  That, or you aren't a very good one.