• "Dario" <supdar yahoo.com> Sep 01 2002
• "Walter" <walter digitalmars.com> Sep 01 2002
• "Sandor Hojtsy" <hojtsy index.hu> Sep 02 2002
• "Dario" <supdar yahoo.com> Sep 02 2002
• "Dario" <supdar yahoo.com> Sep 05 2002
• "Walter" <walter digitalmars.com> Sep 05 2002
• "Walter" <walter digitalmars.com> Sep 04 2002

"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.




 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


 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




 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






 (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


 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






 it).


 It's a good idea.

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




 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().




I don't understand the question.