Hey, what's with this:

if(a === null)

Then does that mean I can do this:

if(a !=== null)

??? I'm sorry, this operator syntax looks stupid!  Honestly!  Why not create an operator 'is':

if(a is null)

Just like in SQL!

Or better yet, why not create a built-in operator, function or property on ALL classes that derive from Object called 'isnull'?  If you do that, you can get rid of the 'null' keyword as it would become obsolete.

if(a.isnull)
if(!a.isnull)

I'm sorry, I don't like '==='.  This is going too far!!

I also don't like '<<<', and I have seen '<<<=' and '>>>=' in javascript.  NOT
PRETTY!!
:(

Sam-
sam987883@yahoo.com

On Wed, 25 May 2005 23:08:34 +0000 (UTC), Sam wrote:

> Hey, what's with this:
> 
> if(a === null)
> 
> Then does that mean I can do this:
> 
> if(a !=== null)
> 
> ??? I'm sorry, this operator syntax looks stupid!  Honestly!  Why not create an operator 'is':
> 
> if(a is null)
> 
> Just like in SQL!

Keep reading the specs. There is an 'is' operator which is an alias for "===". The triple '=' operator is being phased out so I wouldn't use it any more. The "!==" operator is the negative of "is" but moves are afoot to have that replaced by a better operator too.

> Or better yet, why not create a built-in operator, function or property on ALL classes that derive from Object called 'isnull'?  If you do that, you can get rid of the 'null' keyword as it would become obsolete.
> 
> if(a.isnull)
> if(!a.isnull)
> 
> I'm sorry, I don't like '==='.  This is going too far!!

You are not alone, and it was superseded. We are trying hard to get "!==" replaced too.

-- 
Derek
Melbourne, Australia
26/05/2005 9:10:09 AM

Sam wrote:
> Hey, what's with this:
> 
> if(a === null)
> 
> Then does that mean I can do this:
> 
> if(a !=== null)
That would be !==

> 
> ??? I'm sorry, this operator syntax looks stupid!  Honestly!  Why not create an
> operator 'is':
> 
> if(a is null)
>
D now has the "is" operator, with "!is" on the way. "===" and "!==" are looking like they'll get deprecated.

> I also don't like '<<<', and I have seen '<<<=' and '>>>=' in javascript.  NOT
There is no "<<<" expression, and ">>>", unsigned shift right, is a potentially useful operator in places.  Though I doubt you'll see it often considering how rare << and >> are already.

Brad

Sam wrote:

> Hey, what's with this:
> 
> if(a === null)
> 
> Then does that mean I can do this:
> 
> if(a !=== null)

Yes. For now, at least... It's called '!==', though ?
(compare with '==' and '!=' for equality expressions)

Some people (like myself) think that's a *good* thing...
(I happened to like the === [≡] and !== [≢], too bad)

> ??? I'm sorry, this operator syntax looks stupid!  Honestly!  Why not create an
> operator 'is':
> 
> if(a is null)
> 
> Just like in SQL!

Must be your lucky day then. Your wish has been granted,
Walter has now deprecated the '===' identity expressions...

"if (a is null)" is legal D code, since DMD 0.76 (Nov 2003).
The naming jury is still out on the "not" version of 'is'.

> Or better yet, why not create a built-in operator, function or property on ALL
> classes that derive from Object called 'isnull'?  If you do that, you can get
> rid of the 'null' keyword as it would become obsolete.
> 
> if(a.isnull)
> if(!a.isnull)

But you would still need 'null' for pointers ?

And currently D uses:
if (a)
if (!a)

But that might change too, some future day...

--anders

>> Or better yet, why not create a built-in operator, function or property on ALL classes that derive from Object called 'isnull'?  If you do that, you can get rid of the 'null' keyword as it would become obsolete.
>> 
>> if(a.isnull)
>> if(!a.isnull)
>
>But you would still need 'null' for pointers ?

a.makenull();

How about this???  I still believe the 'null' keyword can be deprecated!  :-O

Sam-
sam987883@yahoo.com

But people used to C++ are going to appreciate it.  And C# also uses null.

I really don't see why having null is a problem.  And I would never support anything that would make this:

Class a;
if (a.isnull)

Legal, but this:

Class a;
if (a.prop)

A segfault.  Yuck, talk about confusing for newbies.

-[Unknown]


>>>Or better yet, why not create a built-in operator, function or property on ALL
>>>classes that derive from Object called 'isnull'?  If you do that, you can get
>>>rid of the 'null' keyword as it would become obsolete.
>>>
>>>if(a.isnull)
>>>if(!a.isnull)
>>
>>But you would still need 'null' for pointers ?
> 
> 
> a.makenull();
> 
> How about this???  I still believe the 'null' keyword can be deprecated!  :-O
> 
> Sam-
> sam987883@yahoo.com

You're right!!  What was I smoking!!  Sorry!

What I meant was some static methods:

class a {}

if(!Object::isnull(a))
Object::makenull(a);

How about these?  They don't have to be under class Object:

if(D::isnull(a))
D::nullify(a);

D-licious!!

In article <d74rpa$2miv$1@digitaldaemon.com>, Unknown W. Brackets says...
>
>But people used to C++ are going to appreciate it.  And C# also uses null.
>
>I really don't see why having null is a problem.  And I would never support anything that would make this:
>
>Class a;
>if (a.isnull)
>
>Legal, but this:
>
>Class a;
>if (a.prop)
>
>A segfault.  Yuck, talk about confusing for newbies.
>
>-[Unknown]
>
>
>>>>Or better yet, why not create a built-in operator, function or property on ALL classes that derive from Object called 'isnull'?  If you do that, you can get rid of the 'null' keyword as it would become obsolete.
>>>>
>>>>if(a.isnull)
>>>>if(!a.isnull)
>>>
>>>But you would still need 'null' for pointers ?
>> 
>> 
>> a.makenull();
>> 
>> How about this???  I still believe the 'null' keyword can be deprecated!  :-O
>> 
>> Sam-
>> sam987883@yahoo.com

Sam wrote:

>>But you would still need 'null' for pointers ?
> 
> a.makenull();
> 
> How about this???  I still believe the 'null' keyword can be deprecated!  :-O

You mean you would define some built-in properties for
regular pointers as well ? Like "isnull", for instance.

And even add methods to them ? Like this "makenull" here.
Without having it dereference it, like other such calls ?


Sounds kinda confusing. Especially with any pointers to structs...
(trying to guess which are built-in properties, which are fields ?)

And I really don't think "p.isnull()" is clearer than "p == null".
It might be a little clearer than "p", but that's another topic.

--anders

PS.
void* p; // not an object, as '== null' segfaults with those.

Well, it would be:

if (!Object.isnull(a))
   ...
else
   Object.nullify(a);

But, still, that's longer than:

if (a is null)
   ...
else
   a = null;

And also less clear.  I don't think it is D's purpose to kill or hide pointers, either, and null is useful with pointers as well (essentially the same as 0, but much more clear.)

What I'm having trouble understanding is really what problem this is meant to address; just that you don't like ===, is, and null?

-[Unknown]


> You're right!!  What was I smoking!!  Sorry!
> 
> What I meant was some static methods:
> 
> class a {}
> 
> if(!Object::isnull(a))
> Object::makenull(a);
> 
> How about these?  They don't have to be under class Object:
> 
> if(D::isnull(a))
> D::nullify(a);
> 
> D-licious!!

Ok then why not put 'isnull' and 'nullify' into a namespace or make them built-in?

Then:

if(isnull(a))
..
else
nullify(a);

Granted it's not as small as the syntax with 'is' and 'null', but this
eliminates the need for 'is' and 'null'.
You see, to me my way is simpler:

if(isnull(a)) // 1 isnull method, 1 argument
if(a is null) // 1 is operator, 2 arguments (1 special keyword)

nullify(a) // 1 method, 1 argument
a = null   // 1 operator, 2 arguments (1 special keyword)

if(!isnull(a)) // 1 ! operator, 1 isnull method, 1 argument
if(a !== null) // 1 !== operator, 2 arguments (1 special keyword)


I am for a 'not' keyword though!!  It's better than this '!' that carried over from c++!

Recap of what I propose:

Get rid of: 'null', 'true', 'false', '!', '!==', 'is'
Add:        'not', 'isnull', 'nullify', 'truthify', 'falsify'

;-D

In article <d7502f$2q6o$1@digitaldaemon.com>, Unknown W. Brackets says...
>
>Well, it would be:
>
>if (!Object.isnull(a))
>    ...
>else
>    Object.nullify(a);
>
>But, still, that's longer than:
>
>if (a is null)
>    ...
>else
>    a = null;
>
>And also less clear.  I don't think it is D's purpose to kill or hide pointers, either, and null is useful with pointers as well (essentially the same as 0, but much more clear.)
>
>What I'm having trouble understanding is really what problem this is meant to address; just that you don't like ===, is, and null?
>
>-[Unknown]
>