tetsuya wrote:
> In article <cpkm0l$29rc$1@digitaldaemon.com>,
> =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
> 
>>tetsuya wrote:
>>
>>
>>>4. /+ +/ comments out, /++ +/ uncomments
>>>
>>>While debugging with nested comments, I realized that I always
>>>had to remember where to comment out so that I could make things
>>>back.  Letting /++ +/ make the code inside valid again would be
>>>a very good way to solve this problem and make D's nested comment
>>>more comparable to the '#if 0 ... #endif' stuff in C/C++.

I don't quite understand what you're suggesting, but I like the way that nested comments currently work. I don't see a need for improving it, but  maybe that's just because I haven't run into the problem you're trying to solve.

>>
>>You should not use comments to disable code,
>>instead you could use either "debug { }", or
>>version(none) or version(all) for #if 0 or 1...
>>
>>/+ +/ isn't used for much else than commenting
>>out code, that had been commented with /* */
>>
>>--anders

I agree with that.

> Thanks for the suggestion.  I'll take that.
> 
> But then what are nested comments used for?
> Seems like there's not so much need for it.
> 
> -tetsuya

True, they aren't right for every situation, but nested comments have come in very handy for me when I'm trying to nail down a bug. If something weird is happening (but I'm not sure where the problem is), I might used nested comments to comment out a large section. If I still see the problem, I can enlarge the commented section again by nesting the first commented area and adding another section. Take my word for it, they are useful the way they currently work.

In my mind, the nested comments should be removed from code once the bugs are fixed. If the contained code isn't needed anymore, then it should be removed altogether of course.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

J C Calvarese schrieb am Mon, 13 Dec 2004 17:39:29 -0600:
> In my mind, the nested comments should be removed from code once the bugs are fixed. If the contained code isn't needed anymore, then it should be removed altogether of course.

How about using version(none){} ? ...

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFBviyD3w+/yD4P9tIRAqhCAKCLKgPmAZKeMmtK5OUHE2uPvUnA2wCbB5ak
b9QYV1FKnTp4f4xB3N3hRwc=
=gfml
-----END PGP SIGNATURE-----

"tetsuya" <tetsuya_member@pathlink.com> escribió en el mensaje
news:cpkagp$1s59$1@digitaldaemon.com...
|
| 3. assert(Object) checks null-ness, assert(Object.invariant) checks contract
|
| Since 'if (Object)' checks if it is null or not, I thought
| it is not so reasonable to make assert(Object) check its
| invariability.  In the proposed way, the code also has clarity
| in its meanings.
|

You can always do "assert(Object !== null);"

|
|
| 4. /+ +/ comments out, /++ +/ uncomments
|
| While debugging with nested comments, I realized that I always
| had to remember where to comment out so that I could make things
| back.  Letting /++ +/ make the code inside valid again would be
| a very good way to solve this problem and make D's nested comment
| more comparable to the '#if 0 ... #endif' stuff in C/C++.
|
|

I use them. Here's what I do to uncomment:

//+
...code...
//+/

Remove the first slash to comment, add it to uncomment.

-----------------------
Carlos Santander Bernal

In article <cplfsf$5mu$1@digitaldaemon.com>, Carlos Santander B. says...
>
>"tetsuya" <tetsuya_member@pathlink.com> escribió en el mensaje
>news:cpkagp$1s59$1@digitaldaemon.com...
>|
>| 3. assert(Object) checks null-ness, assert(Object.invariant) checks contract
>|
>| Since 'if (Object)' checks if it is null or not, I thought
>| it is not so reasonable to make assert(Object) check its
>| invariability.  In the proposed way, the code also has clarity
>| in its meanings.
>|
>
>You can always do "assert(Object !== null);"
>

IIRC, there's no operation !== in D, instead
"assert(! (Object is null));" will do the job.

But what I meant was not wether it can be done in current
spec, but treating the expression in 'assert' as
different from that in 'if' and others would be somehow
confusing because both are dealing with conditions, or
booleans.

>|
>|
>| 4. /+ +/ comments out, /++ +/ uncomments
>|
>| While debugging with nested comments, I realized that I always
>| had to remember where to comment out so that I could make things
>| back.  Letting /++ +/ make the code inside valid again would be
>| a very good way to solve this problem and make D's nested comment
>| more comparable to the '#if 0 ... #endif' stuff in C/C++.
>|
>|
>
>I use them. Here's what I do to uncomment:
>
>//+
>...code...
>//+/
>
>Remove the first slash to comment, add it to uncomment.
>
>-----------------------
>Carlos Santander Bernal
>
>

Thanks.  I just suggested because I never knew version(none)
and version(all) could be used to comment codes.  Now I will
use that.  I admit that it wasn't a good idea, just forget it.
>> To all those who are threatened by that idea
I'm done with nested comment stuff now :)

-tetsuya

"tetsuya" <tetsuya_member@pathlink.com> escribió en el mensaje
news:cpln80$d07$1@digitaldaemon.com...
| IIRC, there's no operation !== in D, instead
| "assert(! (Object is null));" will do the job.
|

Err...

void main ()
{
    Object o = new Object;
    assert ( o !== null );
}

Compiles, links and run.

-----------------------
Carlos Santander Bernal

In article <cplp97$f65$1@digitaldaemon.com>, Carlos Santander B. says...
>
>"tetsuya" <tetsuya_member@pathlink.com> escribió en el mensaje
>news:cpln80$d07$1@digitaldaemon.com...
>| IIRC, there's no operation !== in D, instead
>| "assert(! (Object is null));" will do the job.
>|
>
>Err...
>
>void main ()
>{
>    Object o = new Object;
>    assert ( o !== null );
>}
>
>Compiles, links and run.

Ouch!!! Sorry about that. I'm embarraseed..
I should have tested before posting.

There might be some more things I can't just reason from the
documents..
Gotta be care > myself.

>
>-----------------------
>Carlos Santander Bernal
>
>

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> J C Calvarese schrieb am Mon, 13 Dec 2004 17:39:29 -0600:
> 
>>In my mind, the nested comments should be removed from code once the bugs are fixed. If the contained code isn't needed anymore, then it should be removed altogether of course.
> 
> 
> How about using version(none){} ? ...
> 
> Thomas

I was referring to code that has outlived its usefulness or that was worthless to begin with. I'd assume that version(none){} would be reserved for code that might be useful. Each tool has its purpose. More tools are better than fewer tools.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

> I didn't mean to say preprocessor is superior than what D offers as its alternatives.  I was just feeling that C's way (switching by simply altering 0 or 1) is one of a few things where C is a little more programmer-friendly.

Maybe you can use if(1) and if(0), or version(any) and version(none) instead?

L.

Hi.. Just a quicky.

> 1. auto-calculation of static array length
> [...]

I agree, but not by using 'const'. Why not make it a constant-length array instead of a dynamic one? Or maybe use "..." for, as in "int[...] a" or "int[] a = [1,2,...];"  :-S

> 2. 'this' in struct is not a pointer, but an instance
> [...]

I agree that 'this' in D should behave like C++'s '*this'. If some pro wants the pointer, he can always do '&this'.

> 3. assert(Object) checks null-ness, assert(Object.invariant) checks
> contract
> [...]

I agree with you.

> 4. /+ +/ comments out, /++ +/ uncomments
> [...]

Confusing.

> 5. .init propery of function arguments
> [...]

Making <instance>.init different from <type>.init seems too big a change, since .init is something like a static property of a class.

> 6. special scope rules in contract
> [...]

Aren't the contracts compiled-in optionally? This would mean that if you don't want the contracts to be tested, the declaration in the in/out blocks should still be compiled, but not the statements? Odd.

> 7. do-while scope rule (proposed before)
> [...]

Got my vote too!

L.

In article <cpm4pt$ps7$1@digitaldaemon.com>, Lionello Lunesu says...
>
>Hi.. Just a quicky.
>
>> 1. auto-calculation of static array length
>> [...]
>
>I agree, but not by using 'const'. Why not make it a constant-length array instead of a dynamic one? Or maybe use "..." for, as in "int[...] a" or "int[] a = [1,2,...];"  :-S

In fact, I don't care what the syntax's gonna be.
I just wanted the compiler's auto-calculation.
So let's leave to Walter what sugar to eat :)


>> 2. 'this' in struct is not a pointer, but an instance
>> [...]
>
>I agree that 'this' in D should behave like C++'s '*this'. If some pro wants the pointer, he can always do '&this'.

Exactly!


[snip]

>> 5. .init propery of function arguments
>> [...]
>
>Making <instance>.init different from <type>.init seems too big a change, since .init is something like a static property of a class.

Not actually ;)
'int.init' is assured to be 'cast(int) 0', but
'<variable_name>.init' is not.
For example, the test below shows the interesting behavior
of .init.

<code>
unittest
{
int x = 5;
assert(x.init == 5);
}

unittest
{
int x;
x = 5;
assert(x.init == int.init);
}
</code>


>> 6. special scope rules in contract
>> [...]
>
>Aren't the contracts compiled-in optionally? This would mean that if you don't want the contracts to be tested, the declaration in the in/out blocks should still be compiled, but not the statements? Odd.

Hmm, I guess I need an example to understand it well.


>> 7. do-while scope rule (proposed before)
>> [...]
>
>Got my vote too!
>
>L.


-tetsuya