• Dario (22/22) Sep 01 2002 1) out parameters with initializers.
• Walter (6/28) Sep 01 2002 You're right, it's a lapse in consistency. I'd be a little worried about...
• Sandor Hojtsy (6/40) Sep 02 2002 (I
• Dario (4/45) Sep 02 2002 I guess it compare references! =)
• Dario (16/16) Sep 05 2002 Quoting from object.d
• Walter (5/21) Sep 05 2002 ...",
• Walter (3/5) Sep 04 2002 I don't understand the question.

"Dario" <supdar yahoo.com> writes:

1) out parameters with initializers.

Out parameters are initialized by the callee. So we should be able to
override the default initializer as we do with any other variable, for
example:
void func(out int a = 5) { a++; }

I've never needed it since now, but it should be added for consistency. (I
don't know if this has been proposed before...)

2) switching through classinfoes

switch(a.classinfo)
{
    case A.classinfo:
    do something;
    break;

    case B.classinfo:
    do something else;
    break;

    default:
}

This isn't working now. I think this is very useful (I've already needed
it).
In this case the compiler should compare references, not classes (does it
already do this when comparing classinfoes with op==?).

"Walter" <walter digitalmars.com> writes:

"Dario" <supdar yahoo.com> wrote in message
news:aku59v$1grs$1 digitaldaemon.com...
 1) out parameters with initializers.

 Out parameters are initialized by the callee. So we should be able to
 override the default initializer as we do with any other variable, for
 example:
 void func(out int a = 5) { a++; }

 I've never needed it since now, but it should be added for consistency. (I
 don't know if this has been proposed before...)

You're right, it's a lapse in consistency. I'd be a little worried about it,
though, as C++ programmers will think it means a default parameter.

 2) switching through classinfoes

 switch(a.classinfo)
 {
     case A.classinfo:
     do something;
     break;

     case B.classinfo:
     do something else;
     break;

     default:
 }

 This isn't working now. I think this is very useful (I've already needed
 it).

It's a good idea.

 In this case the compiler should compare references, not classes (does it
 already do this when comparing classinfoes with op==?).

=== comparse references, == calls Object.eq().

"Sandor Hojtsy" <hojtsy index.hu> writes:

"Walter" <walter digitalmars.com> wrote in message
news:akue2o$1q99$1 digitaldaemon.com...
 "Dario" <supdar yahoo.com> wrote in message
 news:aku59v$1grs$1 digitaldaemon.com...
 1) out parameters with initializers.

 Out parameters are initialized by the callee. So we should be able to
 override the default initializer as we do with any other variable, for
 example:
 void func(out int a = 5) { a++; }

 I've never needed it since now, but it should be added for consistency.


(I
 don't know if this has been proposed before...)

 You're right, it's a lapse in consistency. I'd be a little worried about

it,
 though, as C++ programmers will think it means a default parameter.

 2) switching through classinfoes

 switch(a.classinfo)
 {
     case A.classinfo:
     do something;
     break;

     case B.classinfo:
     do something else;
     break;

     default:
 }

 This isn't working now. I think this is very useful (I've already needed
 it).

 It's a good idea.

 In this case the compiler should compare references, not classes (does


it
 already do this when comparing classinfoes with op==?).

 === comparse references, == calls Object.eq().

Then what does Object.eq() for classinfos?

"Dario" <supdar yahoo.com> writes:

 1) out parameters with initializers.

 Out parameters are initialized by the callee. So we should be able to
 override the default initializer as we do with any other variable, for
 example:
 void func(out int a = 5) { a++; }

 I've never needed it since now, but it should be added for



consistency.
 (I
 don't know if this has been proposed before...)

 You're right, it's a lapse in consistency. I'd be a little worried about

 it,
 though, as C++ programmers will think it means a default parameter.

 2) switching through classinfoes

 switch(a.classinfo)
 {
     case A.classinfo:
     do something;
     break;

     case B.classinfo:
     do something else;
     break;

     default:
 }

 This isn't working now. I think this is very useful (I've already



needed
 it).

 It's a good idea.

 In this case the compiler should compare references, not classes (does


 it
 already do this when comparing classinfoes with op==?).

 === comparse references, == calls Object.eq().

 Then what does Object.eq() for classinfos?

I guess it compare references! =)
Doesn't it, Walter?

"Dario" <supdar yahoo.com> writes:

Quoting from object.d

class Object
{
int cmp(Object o)
{
    return (int)(void*)this - (int)(void*)o;
}

int eq(Object o)
{
    return this === o;
}
// something else
}

I don't understand what Object.cmp(Object) is useful for...
I would prefer the compiler to emit an error like "No cmp() for class ...",
because if I try to do that comparison I'm probably making a mistake.

"Walter" <walter digitalmars.com> writes:

"Dario" <supdar yahoo.com> wrote in message
news:al7m9o$4vj$1 digitaldaemon.com...
 Quoting from object.d

 class Object
 {
 int cmp(Object o)
 {
     return (int)(void*)this - (int)(void*)o;
 }

 int eq(Object o)
 {
     return this === o;
 }
 // something else
 }

 I don't understand what Object.cmp(Object) is useful for...
 I would prefer the compiler to emit an error like "No cmp() for class

...",
 because if I try to do that comparison I'm probably making a mistake.

What it does is a sort based on its position in memory. But I think you're
right.

"Walter" <walter digitalmars.com> writes:

"Sandor Hojtsy" <hojtsy index.hu> wrote in message
news:akvas9$2vak$1 digitaldaemon.com...
 === comparse references, == calls Object.eq().

 Then what does Object.eq() for classinfos?

I don't understand the question.