January 24, 2005
On Tue, 25 Jan 2005 08:08:27 +1100, Matthew <admin.hat@stlsoft.dot.org> wrote:
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
>> IMO if(x) should be made the official form of this idiom, in D.
>>
>> And documented as such.
>>
>> Every language has its preferred idioms, and every idiom can be attacked as unobvious, dangerous, etc. But having
>> these idioms is what makes the language more fluent and usable.
>>
>> The standard idioms make source code much more readable.
>
> That's nice, and in almost all other ways I've fallen into line with the D way of things - no more whinges about
> boolean, using dCaseMethods, etc. etc. But there's no way I'm writing non-boolean conditional (sub-)expressions. Sorry.

Now I'm curious. Why not?

Regan
January 24, 2005
agent.smith@archvillain.com wrote:

>>>if( x.valid )   // new property of pointers
>>
>>What if x is null, though ? Does null have any properties ?'
> 
> variable x has properties, since it has a type.
> Nullness or non-nullness is a run-time condition. The existence
> of the property is determined at compile-time; the value
> is determined at run-time. 

Right, properties work even on null objects. Such as length on char[],
which returns 0 for null strings. (comes in handy when comparing them)

It's just things such as equality that fails to check on null objects.
As in: if (null == x), which works for pointers but fails for objects.

Forgot that, thanks.

--anders
January 25, 2005
"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsk4lnexa23k2f5@ally...
> On Tue, 25 Jan 2005 08:08:27 +1100, Matthew <admin.hat@stlsoft.dot.org>  wrote:
>> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
>>> IMO if(x) should be made the official form of this idiom, in D.
>>>
>>> And documented as such.
>>>
>>> Every language has its preferred idioms, and every idiom can be  attacked as unobvious, dangerous, etc. But having these idioms is what makes the language more fluent and usable.
>>>
>>> The standard idioms make source code much more readable.
>>
>> That's nice, and in almost all other ways I've fallen into line with the  D way of things - no more whinges about boolean, using dCaseMethods, etc. etc. But there's no way I'm writing  non-boolean conditional (sub-)expressions. Sorry.
>
> Now I'm curious. Why not?

Just experience over these long years. Explicit boolean conditional (sub-)expressions never cause problems. Implicit ones sometimes do. Therefore I adopt a habit of always doing it to avoid the occasional cases. QED


January 25, 2005
On Tue, 25 Jan 2005 12:56:53 +1100, Matthew <admin.hat@stlsoft.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsk4lnexa23k2f5@ally...
>> On Tue, 25 Jan 2005 08:08:27 +1100, Matthew <admin.hat@stlsoft.dot.org>  wrote:
>>> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
>>>> IMO if(x) should be made the official form of this idiom, in D.
>>>>
>>>> And documented as such.
>>>>
>>>> Every language has its preferred idioms, and every idiom can be  attacked as unobvious, dangerous, etc. But having
>>>> these idioms is what makes the language more fluent and usable.
>>>>
>>>> The standard idioms make source code much more readable.
>>>
>>> That's nice, and in almost all other ways I've fallen into line with the  D way of things - no more whinges about
>>> boolean, using dCaseMethods, etc. etc. But there's no way I'm writing  non-boolean conditional (sub-)expressions.
>>> Sorry.
>>
>> Now I'm curious. Why not?
>
> Just experience over these long years. Explicit boolean conditional (sub-)expressions never cause problems. Implicit
> ones sometimes do. Therefore I adopt a habit of always doing it to avoid the occasional cases. QED

I use them all the time.. I've never had any trouble (that I can remember), can you give me an example you've run into (I might want/need to scan my recent code for it).

Regan
January 25, 2005
"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsk4y49nq23k2f5@ally...
> On Tue, 25 Jan 2005 12:56:53 +1100, Matthew <admin.hat@stlsoft.dot.org>  wrote:
>> "Regan Heath" <regan@netwin.co.nz> wrote in message  news:opsk4lnexa23k2f5@ally...
>>> On Tue, 25 Jan 2005 08:08:27 +1100, Matthew  <admin.hat@stlsoft.dot.org>  wrote:
>>>> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
>>>>> IMO if(x) should be made the official form of this idiom, in D.
>>>>>
>>>>> And documented as such.
>>>>>
>>>>> Every language has its preferred idioms, and every idiom can be   attacked as unobvious, dangerous, etc. But
>>>>> having
>>>>> these idioms is what makes the language more fluent and usable.
>>>>>
>>>>> The standard idioms make source code much more readable.
>>>>
>>>> That's nice, and in almost all other ways I've fallen into line with  the  D way of things - no more whinges about boolean, using dCaseMethods, etc. etc. But there's no way I'm writing   non-boolean conditional (sub-)expressions. Sorry.
>>>
>>> Now I'm curious. Why not?
>>
>> Just experience over these long years. Explicit boolean conditional  (sub-)expressions never cause problems. Implicit ones sometimes do. Therefore I adopt a habit of always doing it to avoid  the occasional cases. QED
>
> I use them all the time.. I've never had any trouble (that I can  remember), can you give me an example you've run into (I might want/need  to scan my recent code for it).

Well, naturally not. Since I have been doing it this way for about 5 years, I don't have any real ones to offer up. :-)


January 25, 2005
On Tue, 25 Jan 2005 15:16:46 +1100, Matthew <admin.hat@stlsoft.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsk4y49nq23k2f5@ally...
>> On Tue, 25 Jan 2005 12:56:53 +1100, Matthew <admin.hat@stlsoft.dot.org>  wrote:
>>> "Regan Heath" <regan@netwin.co.nz> wrote in message  news:opsk4lnexa23k2f5@ally...
>>>> On Tue, 25 Jan 2005 08:08:27 +1100, Matthew  <admin.hat@stlsoft.dot.org>  wrote:
>>>>> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
>>>>>> IMO if(x) should be made the official form of this idiom, in D.
>>>>>>
>>>>>> And documented as such.
>>>>>>
>>>>>> Every language has its preferred idioms, and every idiom can be   attacked as unobvious, dangerous, etc. But
>>>>>> having
>>>>>> these idioms is what makes the language more fluent and usable.
>>>>>>
>>>>>> The standard idioms make source code much more readable.
>>>>>
>>>>> That's nice, and in almost all other ways I've fallen into line with  the  D way of things - no more whinges about
>>>>> boolean, using dCaseMethods, etc. etc. But there's no way I'm writing   non-boolean conditional (sub-)expressions.
>>>>> Sorry.
>>>>
>>>> Now I'm curious. Why not?
>>>
>>> Just experience over these long years. Explicit boolean conditional  (sub-)expressions never cause problems. Implicit
>>> ones sometimes do. Therefore I adopt a habit of always doing it to avoid  the occasional cases. QED
>>
>> I use them all the time.. I've never had any trouble (that I can  remember), can you give me an example you've run
>> into (I might want/need  to scan my recent code for it).
>
> Well, naturally not. Since I have been doing it this way for about 5 years, I don't have any real ones to offer up. :-)

Oh... maybe someone else can come up with one? anyone?

Regan
January 25, 2005
On 2005-01-21 08:14:02 -0600, John Reimer <brk_6502@yahoo.com> said:

> Anders F Björklund wrote:
> 
>> PS. I take it that's another one against "aint" ?
> 
> Heh, "aint" just doesn't cut it. :-)


I think 'aint' would be great!

 if (p aint null) ill_be_damed ();

 if (you aint good) goto hell;

Now as a Texan, that's speaking my language. ;-)

January 25, 2005
On 2005-01-21 09:14:11 -0600, =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb@algonet.se> said:

> parabolis wrote:
> 
>>> But if you really like some new words, then I suggest ≥ and ≤ ?
>> 
>> I absolutely agree with this suggestion. I would further it by suggesting "≡≡" and "!≡" replace the current "is"
> 
> No, not replace. As an *alternative* to the US-ASCII syntax.
> And that should be ≡ for '===', and ≢ for '!==' by the way.
> 
> http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/UnicodeOperators
> 
> --anders

Yes I agree! I think it makes for more easily readable and compact looking code. I would love to see this.

January 25, 2005
Brian Chapman wrote:

>  if (p aint null) ill_be_damed ();

I don't generally correct spelling errors but I think you meant 'ahl_be_dahmned();' ; )
January 25, 2005
Brian Chapman wrote:

>> No, not replace. As an *alternative* to the US-ASCII syntax.
>> And that should be ≡ for '===', and ≢ for '!==' by the way.
>>
>> http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/UnicodeOperators 
> 
> Yes I agree! I think it makes for more easily readable and compact looking code. I would love to see this.

The following were suggested, as a start:

> ≟     may be used instead of     ==
> ≠     may be used instead of     !=
> ≤     may be used instead of     <=
> ≥     may be used instead of     >=
> ≡     may be used instead of     ===
> ≢     may be used instead of     !==
> ∧     may be used instead of     &&
> ∨     may be used instead of     ||

(printed using the following D program:)

> void main()
> {
>    printf("\u225F     may be used instead of     ==\n");
>    printf("\u2260     may be used instead of     !=\n");
>    printf("\u2264     may be used instead of     <=\n");
>    printf("\u2265     may be used instead of     >=\n");
>    printf("\u2261     may be used instead of     ===\n");
>    printf("\u2262     may be used instead of     !==\n");
>    printf("\u2227     may be used instead of     &&\n");
>    printf("\u2228     may be used instead of     ||\n");
> }

It's one way to put the UTF-8 to some use...

--anders

PS. Here's images, if your browser is Unicode-challenged:
http://www.fileformat.info/info/unicode/char/225F/index.htm
http://www.fileformat.info/info/unicode/char/2260/index.htm
http://www.fileformat.info/info/unicode/char/2264/index.htm
http://www.fileformat.info/info/unicode/char/2265/index.htm
http://www.fileformat.info/info/unicode/char/2261/index.htm
http://www.fileformat.info/info/unicode/char/2262/index.htm
http://www.fileformat.info/info/unicode/char/2227/index.htm
http://www.fileformat.info/info/unicode/char/2228/index.htm