"davepermen" <davepermen_member@pathlink.com> wrote in message news:cf60oo$1pt$1@digitaldaemon.com...
> In article <cf31k5$223l$2@digitaldaemon.com>, Walter says...
> >
> >
> >"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:cf2qfj$1toe$1@digitaldaemon.com...
> >> personally i don't see what's wrong with
> >> operator+() , but oh well.
> >
> >operator+ doesn't work when you need both the forward and the 'r'
versions
> >of an operator overload. Also, opCmp handles <, <=, >, >=. And lastly,
opCmp
> >is eminently greppable.
> >
> >
>
> i'd still prefer operator cmp() and similar. opAnything looks ugly.
operator
> Anything() not (imho). but thats me.. and doesn't really mather

I think it's advantageous to have a predictable and recognizable 'look' for operator overload function names, since they don't have a keyword setting them off.

Ant wrote:
<snip>
> How else can an array of objects be sorted?
> what problems do they cause?

Can you think of a scenario in which an array of objects, of no common base class besides Object, would be mutually comparable?

Stewart.

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

Ivan Senji wrote:
<snip>
> What is so special about opCmp, (ok it is used in AAs but
> couldn't compiler report: "this type cann't be used in AA because
> of the missing opCmp!")
<snip>

If the compiler were capable of that, it would be equally capable of hooking up an alternative AA implementation that doesn't depend on opCmp.

See also

http://www.digitalmars.com/drn-bin/wwwnews?D/26144
http://www.digitalmars.com/drn-bin/wwwnews?D/26193
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5406

Stewart.

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

Ivan Senji wrote:

> There are bigger problems but:
> 
> Can please these:
>     int opCmp(Object o);
>     int opEquals(Object o);
> 
> be removed from Object!
<snip>

Been suggested many a time.  Several links to posts on this issue here:

http://www.wikiservice.at/wiki4d/wiki.cgi?PendingPeeves

Not getting rid of these (at least opCmp) is a bit like not trying to give up smoking - every excuse I have seen has a rebuttal.

Stewart.

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

Arcane Jill wrote:
<snip>
> But we /can/ have our cake and eat it. [SUGGESTION:] Associative arrays don't
> need opCmp(). Honestly, they don't. Why not? - because the only thing AAs
> require is a sort criterion.

They don't even need that.  In reality, they only need an equality criterion.

At the moment, AAs rely on three methods: toHash, opCmp, opEquals.  The opCmp stage could easily be skipped if it doesn't exist, if only it weren't for Object.opCmp.

> That sort criterion does not have to be based on <.
> The current implementation of AAs is to sort based on (x < y), but then to have
> Object define < such that (x < y) is implemented as (&x < &y). So why not just
> have the sort criterion for AAs be (&x < &y) instead of (x < y)?

Generally, equality of objects is completely independent of their relative memory addresses.

Also, screwing up GC:

" Depending on the ordering of pointers:

	if (p1 < p2)		// error: undefined behavior
	    ...
	

since, again, the garbage collector can move objects around in memory."

But that itself depends on too many things:

http://www.digitalmars.com/drn-bin/wwwnews?D/26273

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

Ivan Senji wrote:

<snip>
> Isn't this identity? x === x ?
> That is what we have a great seperate operator === and !== for.
> Why should we also have == be defined by default to do the same as ===.
> Ridicolous!
<snip>

We rebutted this argument of yours a while back:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/3419

and the chain of followups.  Do you have a further defence of your position here?

Stewart.

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

In article <cf61ji$1vh$1@digitaldaemon.com>, Ivan Senji says...
>
>> Basing AAs on the user implemented opCmp is not a good idea, since it's
>behavior
>> is not defined.
>
>What do you mean by undefined behaviour?
>(...)
>Maybe your objects are strange? In most cases my for my classes the two
>objects are either a<b or a==b (or !(a<b))

Yes, that's the point. Maybe I WANT strange objects, I should be free to make opCmp work however I want (and independent of ==). And since the docs for AAs don't mention anywhere that they even use opCmp, I should expect my strange objects to work perfectly in an associated array.

>> It's different for std::map, since it's defined and "advertised" as a _sorted_ container, placing certain restrictions on the input type (in the docs.)
>
>I like it the way std::map dos things!

I do too, I love it in fact.

>> Also, STL always allows you to specify a custom ordering functor as an optional template parameter, so < and > might not be used at all if you don't want them to. This is a good practice for DTL to follow, btw :)
>
>Yes it is!
>But what do you think about the subject of removing opCmp and opEquals
>from Object! They prevent us from writing templates that require these
>operators
>because there are default  versions of these, and they probbably don't do
>what
>the author of the class wants!

I agree with you, they should be removed. And take toString and print with you while you're at it. Also, now that writef/writefln is here (and they work great!) having printf and wprintf imported in object.d is just silly. Take them out too. That's my opinion on that :)

Nick

Nick:
>> It's different for std::map, since it's defined and "advertised" as
>> a _sorted_ container, placing certain restrictions on the input type
>> (in the docs.) Also, STL always allows you to specify a custom ordering
>> functor as an optional template parameter, so < and > might not be used
>> at all if you don't want them to. This is a good practice for DTL to
>> follow, btw :)
>>
Matthew:
>
>Those prototypes are already in. (Just not implemented in most cases.)
>

Good to hear! I wasn't implying anything else :) You're doing a great job.

Nick

Nick wrote:

<snip>
> Yes, that's the point. Maybe I WANT strange objects, I should be free
> to make opCmp work however I want (and independent of ==).

If you're going to abuse operator overloading, it follows that you should be aware of the consequences.

D data structures are designed for those of us who use D 'correctly', not for abusers.

> And since the docs for AAs don't mention anywhere that they even use opCmp, I should expect my strange objects to work perfectly in an
> associated array.

Yes, the documentation needs clearing more than a bit here.

<snip>
> I agree with you, they should be removed. And take toString and print
> with you while you're at it.
<snip>

What's wrong with toString?

Stewart.

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

In article <cf808g$m2r$1@digitaldaemon.com>, Stewart Gordon says...
>Nick wrote:
>> And since the docs for AAs don't mention anywhere that they even use opCmp, I should expect my strange objects to work perfectly in an associated array.
>
>Yes, the documentation needs clearing more than a bit here.

Then I think I agree with you on this point.

>
>What's wrong with toString?
>

Ok maybe there's nothing wrong with toString(). But print() seems a bit
unnecessary, all it does is write toString() to stdout.

Nick