April 15, 2005
>> 2. Leave the current DMD behaviour in, and document it properly.
>
> This solution gets my vote.  IMO, there is nothing odd about requiring the implementor provide comparison and equality operators when
> they really want their class to behave like a value type in the first
> place (ie. sortable).

?? I thought the question was about Object.opCmp() to get rid of, not of opCmp() itself? Implementing an opCmp() for your own class is still possible with solution #1, but only these will have an opCmp() then.

This said, i vote for #1.

Ciao
uwe
April 15, 2005
"Kris" <fu@bar.com> wrote in message news:d3mp8g$1t7a$1@digitaldaemon.com...
>
> "pragma" <pragma_member@pathlink.com> wrote ...
> > In article <d3m7do$1bdk$1@digitaldaemon.com>, Stewart Gordon says...
> > >
> > >2. Leave the current DMD behaviour in, and document it properly.
> >
> > This solution gets my vote.  IMO, there is nothing odd about requiring
the
> > implementor provide comparison and equality operators when they really
> want
> > their class to behave like a value type in the first place (ie.
sortable).
> >
> > There is also a precedent for object collections in C#, by requiring the IComparable interface, which requires the "compareTo(Object)" method.
> Java also
> > has the Comparable interface which happens to be identical.  So I think
> we're on
> > the right track by keeping things as-is.
>
> Don't get you, Eric. Are you saying keep the broken opCmp() and opEquals() in Object, and just assume the user will do the right thing by overriding them in their own class? If so, I have to disagree strongly. Such things should be trapped as compile-time errors, not runtime oblique-behaviour.
>
> IMO, they should get ripped out of Object, and then be supported via an Interface or similar. Note that these Object methods were in place long before Interfaces were even available. That might explain a lot :-)
>

Well i agree with you 100%. I always thought we should get rid of them and make them compile-time errors. I really hope people/Walter listen to you!


> I believe toHash() is in the same boat?
>
> - Kris
>
>


April 15, 2005
"kris" <fu@bar.org> wrote in message news:d3nlut$2kl4$1@digitaldaemon.com...
> Just looking for trouble :-)
>
> Supposing the compiler itself did not change ... any other solutions?

The only solution then would be to eschew the built-in containers. (Which I pretty much do anyway, as it happens. ;/ )

>
> - Kris
>
>
> Matthew wrote:
>> Well, aren't you keen to open up all Pandora's boxes in one go!
>>
>> The answer depends on whether we feel that D should be a language that follows interface-based runtime polymorphism, or uses generic approaches. There's no reason why the language cannot be defined such that the compiler will only accept ar.sort() when ar is composed of homogeneous built-in types, or instances of class types that all share a comon base that has an opCmp() defined. Similarly, there's no reason why AAs could not be built only on types that have the appropriate methods.
>>
>> Since this approach also fully supports runtime polymorphic approaches, but does not mandate them, I think it's the best approach. (Obviously)
>>
>> Matthew
>>
>> "Kris" <fu@bar.com> wrote in message news:d3nid8$2hqe$1@digitaldaemon.com...
>>
>>>Aye.
>>>
>>>Supposing the "Three Stooges" were removed ... do you have a
>>>suggestion in
>>>terms of implementation? Are you thinking in terms of Interfaces?
>>>For
>>>example:
>>>
>>>interface Comparable
>>>{
>>> int opEquals (Object o);
>>> int opCmp (Object o);
>>>}
>>>
>>>interface Hashable
>>>{
>>> uint toHash();
>>>}
>>>
>>>Or something else instead?
>>>
>>>- Kris
>>>
>>>
>>>"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d3n7n3$28d4$1@digitaldaemon.com...
>>>
>>>>Current definition:
>>>>
>>>>class Object
>>>>{
>>>>    void print();
>>>>    char[] toString();
>>>>    uint toHash();
>>>>    int opCmp(Object o);
>>>>    int opEquals(Object o);
>>>>}
>>>>
>>>>Only definition that makes sense to me:
>>>>
>>>>class Object
>>>>{
>>>>    char[] toString();
>>>>}
>>>>
>>>>And that's only because toString() is a benign thing. In
>>>>principle,
>>>>it should be:
>>>>
>>>>class Object
>>>>{
>>>>}
>>>>
>>>>
>>>>
>>>
>>>
>> 

April 15, 2005
Kris wrote:
> Aye.
> 
> Supposing the "Three Stooges" were removed ... do you have a suggestion in
> terms of implementation? Are you thinking in terms of Interfaces? For
> example:
> 
> interface Comparable
> {
>   int opEquals (Object o);
>   int opCmp (Object o);
> }

Why not

    int opEquals (Comparable o);
    int opCmp (Comparable o);

Moreover:

- The presence of a concept of equality certainly doesn't correlate directly with the presence of a natural ordering, so let's not pretend it does.

- There's been just as much of a debate over whether Object should have opEquals.  My thought is that the default implementation (a given object is equal only to itself) makes sense, and (in theory) makes it possible to use such a class as an AA key.  But this doesn't by itself equate to a cause for either keeping or removing Object.opEquals - the 'equal only to itself' behaviour would still be the default if it's removed.

> interface Hashable
> {
>   uint toHash();
> }
<snip top of upside-down reply>

Would primitive types implement this interface as well?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.
April 15, 2005
pragma wrote:
<snip>
> There is also a precedent for object collections in C#, by requiring the IComparable interface, which requires the "compareTo(Object)" method.  Java also has the Comparable interface which happens to be identical.
<snip>

Actually, Java 1.5 (aka Java™ 2 Platform Standard Edition 5.0 for some reason I can't imagine) has Comparable as a template, such that compareTo [sic] is defined only on the scope of the comparability.

> So I think we're on the right track by keeping things as-is.

Why do some people seem to think copying others just for the sake of it is the way to go?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.
April 15, 2005
Well, as long as having other methods doesn't reduce performance, I think it's better to let Object have as many "useful" methods as you can give it that would make sense for "most" obects, because people can always choose to redefine them or simply not use them on objects for which they make no sense.

I think though that the default behavior of opEquals should be to call opCmp and compare the results of that call with 0, but that's just my opinion.

I also think that the opCmp default behavior should be to compare for identity first, and if the items being compared are one and the same then return 0 to indicate "no difference" rather than waste time comparing the contents of an item to itself... but to compare the contents of the items if they are not one and the same.

TechnoZeus

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d3n7n3$28d4$1@digitaldaemon.com...
> Current definition:
>
> class Object
> {
>     void print();
>     char[] toString();
>     uint toHash();
>     int opCmp(Object o);
>     int opEquals(Object o);
> }
>
> Only definition that makes sense to me:
>
> class Object
> {
>     char[] toString();
> }
>
> And that's only because toString() is a benign thing. In principle,
> it should be:
>
> class Object
> {
> }
>
>
>


April 15, 2005
"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:d3o2an$4e$1@digitaldaemon.com...
> Kris wrote:
> > Aye.
> >
> > Supposing the "Three Stooges" were removed ... do you have a suggestion in terms of implementation? Are you thinking in terms of Interfaces? For example:
> >
> > interface Comparable
> > {
> >   int opEquals (Object o);
> >   int opCmp (Object o);
> > }
>
> Why not
>
>      int opEquals (Comparable o);
>      int opCmp (Comparable o);
>
> Moreover:
>
> - The presence of a concept of equality certainly doesn't correlate directly with the presence of a natural ordering, so let's not pretend it does.
>
> - There's been just as much of a debate over whether Object should have opEquals.  My thought is that the default implementation (a given object is equal only to itself) makes sense, and (in theory) makes it possible to use such a class as an AA key.  But this doesn't by itself equate to a cause for either keeping or removing Object.opEquals - the 'equal only to itself' behaviour would still be the default if it's removed.
>
> > interface Hashable
> > {
> >   uint toHash();
> > }
> <snip top of upside-down reply>
>
> Would primitive types implement this interface as well?
>
> Stewart.
>
> -- 
> My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Yes, I have also been thinking about that delema.  An ordered comparison implies an underlying order.  Well, technically speaking, there always is one somewhere in the computer, even if it is meaningless to the intended representation of data, but it should be possible flag a specific kind of item as ordered or unordered, and have that property be inhereted by default.

Technically, there should also be a way to indicate "unequal" through the opCmp operator, but that would probably require the results of opCmp to be an enumeration of something like "less", "equal", "greater", "unordered" so that's probably why the opEquals function has independant functionality by default.

TZ


TZ


April 15, 2005

Stewart Gordon wrote:
> pragma wrote:
> <snip>
> 
>> There is also a precedent for object collections in C#, by requiring the IComparable interface, which requires the "compareTo(Object)" method.  Java also has the Comparable interface which happens to be identical.
> 
> <snip>
> 
> Actually, Java 1.5 (aka Java™ 2 Platform Standard Edition 5.0 for some reason I can't imagine) has Comparable as a template, such that compareTo [sic] is defined only on the scope of the comparability.

Actually, Java 1.5 doesn't have templates, but generics.. The Comparable interface is always the same, you can just specify some class when you type, so you don't have to cast as much (just in the source code, that is, after it gets compiled, I believe the result is the same no matter what you type). Basically, Comparable<T> always compiles as Comparable<Object>...


>> So I think we're on the right track by keeping things as-is.
> 
> Why do some people seem to think copying others just for the sake of it is the way to go?

Wouldn't know :)

I'd leave things as is, but redefine

int opCmp(Object o)
{
    if (this is o)
        return 0;

    throw new SomeException("You need to define opCmp(Object) for " ~ o.classinfo.name);
}

uint opHash(Object o)
{
    return 0;
}

After/if/when introspection is added, these two can easily use it to do something more meaningful (for example, find all opCmp functions and choose one based on types, and hash and xor all the fields, respectively)


xs0
April 15, 2005
xs0 wrote:
<snip>
> I'd leave things as is, but redefine
> 
> int opCmp(Object o)
> {
>     if (this is o)

Why not

    if (this == o)

so that if one has defined opEquals, it'll get the message?

>         return 0;
> 
>     throw new SomeException("You need to define opCmp(Object) for " ~ o.classinfo.name);
> }
<snip>

Why should applications tell their users to define opCmp(Object)?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.
April 15, 2005

Stewart Gordon wrote:
> xs0 wrote:
> <snip>
> 
>> I'd leave things as is, but redefine
>>
>> int opCmp(Object o)
>> {
>>     if (this is o)
> 
> 
> Why not
> 
>     if (this == o)
> 
> so that if one has defined opEquals, it'll get the message?

I don't know, really. Could be as well, considering that the default opEquals is the same thing anyway. OTOH, it's not that important. Who will compare only equal objects anyway?


> 
>>         return 0;
>>
>>     throw new SomeException("You need to define opCmp(Object) for " ~ o.classinfo.name);
>> }
> 
> <snip>
> 
> Why should applications tell their users to define opCmp(Object)?

Well, what I said and "comparison not defined for type Blah" are about equally useful to the users (not at all), yet my message is useful at least to coders? And if you just say it's not defined, everybody will come filing bugs about how their opCmp(Blah) actually is defined :)


xs0