View mode: basic / threaded / horizontal-split · Log in · Help
April 15, 2005
Re: Object.opCmp - about time we came to a decision
>> 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
Re: Object.opCmp - about time we came to a decision
"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
Re: Object.opCmp - about time we came to a decision
"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
Re: Object.opCmp - about time we came to a decision
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
Re: Object.opCmp - about time we came to a decision
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
Re: Object.opCmp - about time we came to a decision
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
Re: Object.opCmp - about time we came to a decision
"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
Re: Object.opCmp - about time we came to a decision
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
Re: Object.opCmp - about time we came to a decision
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
Re: Object.opCmp - about time we came to a decision
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
1 2 3 4 5 6
Top | Discussion index | About this forum | D home