www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - opCmp - any consensus

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Haven't been able to follow the debate the last few days. Has a
consensus emerged?
Apr 20 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d46ii5$1cvv$1 digitaldaemon.com...

 Haven't been able to follow the debate the last few days. Has a
 consensus emerged?


You mean the stuff xs0 and I posted about A[] implicitly casting to B[] for 
A:B? It seems like xs0 and I agree it is a type-safety hole but we have 
different ideas about what to do about it. I would like to make the user 
explicitly cast from A[] to B[] (much like an explicit cast from A* to B* is 
required in D). Xs0 posted some suggestions involving syntax with ! or 
in/out to improve the safety. Georg posted that the current behavior is fine 
as it is.

In my interpretation of the rest of the thread I agree with your post 
requesting input from Walter before going much farther. Why redesign opCmp 
if Walter isn't open to changing it?
Apr 20 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d46nhi$1gut$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d46ii5$1cvv$1 digitaldaemon.com...

 Haven't been able to follow the debate the last few days. Has a
 consensus emerged?


 You mean the stuff xs0 and I posted about A[] implicitly casting
 to B[] for A:B? It seems like xs0 and I agree it is a type-safety
 hole but we have different ideas about what to do about it. I
 would like to make the user explicitly cast from A[] to B[] (much
 like an explicit cast from A* to B* is required in D). Xs0 posted
 some suggestions involving syntax with ! or in/out to improve the
 safety. Georg posted that the current behavior is fine as it is.

 In my interpretation of the rest of the thread I agree with your
 post requesting input from Walter before going much farther. Why
 redesign opCmp if Walter isn't open to changing it?


Thanks Ben.

I'd noticed a lot of posts, but each one I dipped into involved the
pathological issue about array casting - I earned myself a gold star
by resisting getting involved for once <g> (I agree with you, btw) -
and I couldn't see any further discussion on the proposal. I'm
guessing there wasn't any.

Walter, can we tempt you out of your shell for a thought on this
one?

Absent that, I'll continue to wait.
Apr 20 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d46ii5$1cvv$1 digitaldaemon.com...

 Haven't been able to follow the debate the last few days. Has a
 consensus emerged?


I was thinking about changing Object.opCmp to return false if the argument
is null. I think that would satisfy most peoples' objections to it.
Apr 21 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d49d7g$12hb$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d46ii5$1cvv$1 digitaldaemon.com...

 Haven't been able to follow the debate the last few days. Has a
 consensus emerged?


 I was thinking about changing Object.opCmp to return false if the 
 argument
 is null. I think that would satisfy most peoples' objections to 
 it.


My opinion - which seems to be shared by at least one other - is 
that that's a minor issue. The real issue is that it doesn't belong 
in Object, and I've presented a (what I think) good proposal for 
fixing the problem. It does require changes to the 
language/compiler, though.
Apr 21 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d49dei$12ji$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message 
 news:d49d7g$12hb$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d46ii5$1cvv$1 digitaldaemon.com...

 Haven't been able to follow the debate the last few days. Has a
 consensus emerged?


 I was thinking about changing Object.opCmp to return false if the 
 argument
 is null. I think that would satisfy most peoples' objections to 
 it.


 My opinion - which seems to be shared by at least one other - is 
 that that's a minor issue. The real issue is that it doesn't 
 belong in Object, and I've presented a (what I think) good 
 proposal for fixing the problem. It does require changes to the 
 language/compiler, though.


Also, would that cover only the case where the null is the rhs 
comperand? If so, IMO, the cure's worse than the disease. If not, 
then a guarded hurrah! (Though that does not obviate the need to get 
it out of Object in the first place.)
Apr 21 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
 news:d49dei$12ji$1 digitaldaemon.com...
 

"Walter" <newshound digitalmars.com> wrote in message 
news:d49d7g$12hb$1 digitaldaemon.com...


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d46ii5$1cvv$1 digitaldaemon.com...


Haven't been able to follow the debate the last few days. Has a
consensus emerged?


I was thinking about changing Object.opCmp to return false if the 
argument
is null. I think that would satisfy most peoples' objections to 
it.


My opinion - which seems to be shared by at least one other - is 
that that's a minor issue. The real issue is that it doesn't 
belong in Object, and I've presented a (what I think) good 
proposal for fixing the problem. It does require changes to the 
language/compiler, though.


 
 Also, would that cover only the case where the null is the rhs 
 comperand? If so, IMO, the cure's worse than the disease. If not, 
 then a guarded hurrah! (Though that does not obviate the need to get 
 it out of Object in the first place.)


I'm with Matthew here. Creating classes of objects, the only person to 
know how, or whether at all, they might be comparable, is the 
programmer. And only the programmer.

Therefore, if he has not implemented (forgotten, or chosen not to) opCmp 
(or whatever equivalent we might have in 6 months), it is not for the 
compiler to _assume_ any kind of comparability.

A stupid example, I might have a class:

class PropertyPatch
{
     int numTrees;
     int area;
}

How would any compiler consider these instances sortable? And with what 
right?

Heh, this conveniently brings us to Table Manners. (Pun intended!)

In SQL, you might have records of PropertyPatch. But, it is customary 
(good table manners) to also have some way of uniquely addressing the 
individual instances.

With databases, you are encouraged to have an extra field, (say PatchID) 
that identifies the item. Because this field has to be unique, and (when 
there's no other candidate for differentiation) it is usually an 
integer, then we -- all of a sudden -- have sortablility. Meanigless as 
such, or not. (Not to mention that whatever we have as instances, they 
have to be individually addressable also outside the computer. Like the 
real physical patches on my ranch: even I gotta know which is which.)

This leads us conveniently to the fact that whenever we do have several 
instances of a class, we simply do have to have something unique with 
which we can distinguish the individual items from each other.

As a result, we can _demand_ that instances be sortable. And, in spite 
of that, I think we can also _demand_ that anybody who creates a class, 
either has to define how to sort the instances, or face an assert error!

----

This means, that if the programmer hasn't, then he'll become aware of it 
early enough.

Now, sortability and equality are two separate issues.

But there is one thing in common between them: a PropertyPatch can only 
be equal and only be sortable, via the explicit definition by the 
programmer himself. (I'm not talking about equivalence here, especially 
as defind as being the same instance.)

I might want a 2 acre 33 tree patch to be equal to a 1 acre 66 tree patch.

((Hmm, on second thought, is it guaranteed that we can have "bit pattern 
equality" as a default? And then just expand on this with programmer 
defined equalities? I guess we can, since I'm unable to imagine a 
situation where two instances having the same bit pattern would be 
considered unequal!))

Otoh, the above (parenthesized) paragraph becomes moot if the PatchID is 
defined! Then no two instances would compare equal by bit pattern. Which 
leads us back to obligatory user-defined equality. Sigh.

----

For "internal purposes", the compiler may use any means it chooses -- in 
situations where the instances have to be handled or ordered -- as long 
as this handling or ordering is invisible to the programmer. (I.e. go 
ahead and use toHash(currentMemoryLocation), if you want. But only where 
the programmer never gets to know about it. One example would be, in 
which order the instances are sent over a stream.)

----

Well, I haven't presented so many solutions in this post. :-(

But, at least, I feel I've found some Right Questions to ask. :-)
Apr 21 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
And what of those cases where it is known but still not implemented?  Better to
have a default.  If someone wants to make something not comparable, then they
can override the default accordingly, I would think... just as Walter is
talking about doing in the case of the argument being null.

This makes much more sense than to remove useful functionality from the
language.

TZ

"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:426857C1.4030007 nospam.org...

 Matthew wrote:

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d49dei$12ji$1 digitaldaemon.com...


"Walter" <newshound digitalmars.com> wrote in message
news:d49d7g$12hb$1 digitaldaemon.com...


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d46ii5$1cvv$1 digitaldaemon.com...


Haven't been able to follow the debate the last few days. Has a
consensus emerged?


I was thinking about changing Object.opCmp to return false if the
argument
is null. I think that would satisfy most peoples' objections to
it.


My opinion - which seems to be shared by at least one other - is
that that's a minor issue. The real issue is that it doesn't
belong in Object, and I've presented a (what I think) good
proposal for fixing the problem. It does require changes to the
language/compiler, though.


 Also, would that cover only the case where the null is the rhs
 comperand? If so, IMO, the cure's worse than the disease. If not,
 then a guarded hurrah! (Though that does not obviate the need to get
 it out of Object in the first place.)


 I'm with Matthew here. Creating classes of objects, the only person to
 know how, or whether at all, they might be comparable, is the
 programmer. And only the programmer.

 Therefore, if he has not implemented (forgotten, or chosen not to) opCmp
 (or whatever equivalent we might have in 6 months), it is not for the
 compiler to _assume_ any kind of comparability.

 A stupid example, I might have a class:

 class PropertyPatch
 {
      int numTrees;
      int area;
 }

 How would any compiler consider these instances sortable? And with what
 right?

 Heh, this conveniently brings us to Table Manners. (Pun intended!)

 In SQL, you might have records of PropertyPatch. But, it is customary
 (good table manners) to also have some way of uniquely addressing the
 individual instances.

 With databases, you are encouraged to have an extra field, (say PatchID)
 that identifies the item. Because this field has to be unique, and (when
 there's no other candidate for differentiation) it is usually an
 integer, then we -- all of a sudden -- have sortablility. Meanigless as
 such, or not. (Not to mention that whatever we have as instances, they
 have to be individually addressable also outside the computer. Like the
 real physical patches on my ranch: even I gotta know which is which.)

 This leads us conveniently to the fact that whenever we do have several
 instances of a class, we simply do have to have something unique with
 which we can distinguish the individual items from each other.

 As a result, we can _demand_ that instances be sortable. And, in spite
 of that, I think we can also _demand_ that anybody who creates a class,
 either has to define how to sort the instances, or face an assert error!

 ----

 This means, that if the programmer hasn't, then he'll become aware of it
 early enough.

 Now, sortability and equality are two separate issues.

 But there is one thing in common between them: a PropertyPatch can only
 be equal and only be sortable, via the explicit definition by the
 programmer himself. (I'm not talking about equivalence here, especially
 as defind as being the same instance.)

 I might want a 2 acre 33 tree patch to be equal to a 1 acre 66 tree patch.

 ((Hmm, on second thought, is it guaranteed that we can have "bit pattern
 equality" as a default? And then just expand on this with programmer
 defined equalities? I guess we can, since I'm unable to imagine a
 situation where two instances having the same bit pattern would be
 considered unequal!))

 Otoh, the above (parenthesized) paragraph becomes moot if the PatchID is
 defined! Then no two instances would compare equal by bit pattern. Which
 leads us back to obligatory user-defined equality. Sigh.

 ----

 For "internal purposes", the compiler may use any means it chooses -- in
 situations where the instances have to be handled or ordered -- as long
 as this handling or ordering is invisible to the programmer. (I.e. go
 ahead and use toHash(currentMemoryLocation), if you want. But only where
 the programmer never gets to know about it. One example would be, in
 which order the instances are sent over a stream.)

 ----

 Well, I haven't presented so many solutions in this post. :-(

 But, at least, I feel I've found some Right Questions to ask. :-)
Apr 22 2005
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
TechnoZeus wrote:

 And what of those cases where it is known but still not implemented?  


<snip top of upside-down reply>

What is "it" here?  And known to whom?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.
Apr 22 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d4ah96$24ha$2 digitaldaemon.com...

 TechnoZeus wrote:

 And what of those cases where it is known but still not implemented?


 <snip top of upside-down reply>

 What is "it" here?  And known to whom?

 Stewart.

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


Sorry.  I thought the meaning would have been clear inthe context of what it
was a reply to.  Obviously, I was mistaken, so here's a translation...

<translation>
And what of those cases where the fact that the object is comparable is known
(by the programmer of that object) but still not implemented?
</translation>

TZ

And what of those cases where it is known but still not implemented?
Apr 23 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 23 Apr 2005 21:39:07 -0500, TechnoZeus wrote:


[snip] 

 Sorry.  I thought the meaning would have been clear inthe context of what it
was a reply to.  Obviously, I was mistaken, so here's a translation...


I too have a real problem with your replies. I have to work hard to
discover what it is you are actually replying to. The problem seems to stem
from your top-posting style. It just makes it too much work to bother
reading your posts. You leave in the posts all the other stuff you are
*not* replying to. It is quite confusing. 

-- 
Derek Parnell
Melbourne, Australia
24/04/2005 8:57:37 PM
Apr 24 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:l9bbk7o31w4s$.13wkgjjxknpmt.dlg 40tude.net...

 On Sat, 23 Apr 2005 21:39:07 -0500, TechnoZeus wrote:


*snip*

 I too have a real problem with your replies. I have to work hard to
 discover what it is you are actually replying to. The problem seems to stem
 from your top-posting style.


*snip*

 -- 
 Derek Parnell
 Melbourne, Australia
 24/04/2005 8:57:37 PM


Thanks for the input.  I'll work on it.

I see many reply styles here.
Top posting, bottom posting, insert posting, etcetera.

So far,
I have only heard complaints about me top posting, which is the
deault for Outlook Express and my prefered style....
and one complaint about not having line breaks in my paragraphs.

You may have already notice that I have been trying to remember to
insert line breaks manually into my paragraphs,
for the sake of people reading my posts through the web interface,
or through any interface that doesn't have automatic word wrap.

Again, thanks for pointing out your
difficulty in dealing with the top down style,
and extended context quoting.
The feedback is appreciated.

TZ
Apr 24 2005
prev sibling parent reply StarCrossed <StarCrossed_member pathlink.com> writes:
In article <d4ad7d$21ev$1 digitaldaemon.com>, TechnoZeus says...

And what of those cases where it is known but still not implemented?  Better to
have a default.  If someone wants to make something not comparable, then they
can override the default accordingly, I would think... just as Walter is
talking about doing in the case of the argument being null.

This makes much more sense than to remove useful functionality from the
language.


total BS

Do u program?
Apr 22 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"StarCrossed" <StarCrossed_member pathlink.com> wrote in message
news:d4ajh6$26kn$1 digitaldaemon.com...

 In article <d4ad7d$21ev$1 digitaldaemon.com>, TechnoZeus says...

And what of those cases where it is known but still not implemented?  Better to
have a default.  If someone wants to make something not comparable, then they
can override the default accordingly, I would think... just as Walter is
talking about doing in the case of the argument being null.

This makes much more sense than to remove useful functionality from the
language.


 total BS

 Do u program?


That doesn't even deserve an answer, but.. yes.

TZ
Apr 23 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 23 Apr 2005 21:40:17 -0500, TechnoZeus wrote:


 "StarCrossed" <StarCrossed_member pathlink.com> wrote in message
news:d4ajh6$26kn$1 digitaldaemon.com...

 In article <d4ad7d$21ev$1 digitaldaemon.com>, TechnoZeus says...

And what of those cases where it is known but still not implemented?  Better to
have a default.  If someone wants to make something not comparable, then they
can override the default accordingly, I would think... just as Walter is
talking about doing in the case of the argument being null.

This makes much more sense than to remove useful functionality from the
language.


 total BS

 Do u program?


 
 That doesn't even deserve an answer, but.. yes.


Well it just wasn't all that obvious. Thanks for clearing it up.

-- 
Derek Parnell
Melbourne, Australia
24/04/2005 9:00:39 PM
Apr 24 2005
next sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:mrypw5e0gsvi.zf6thq5km4k2.dlg 40tude.net...

 On Sat, 23 Apr 2005 21:40:17 -0500, TechnoZeus wrote:


 Well it just wasn't all that obvious. Thanks for clearing it up.

 -- 
 Derek Parnell
 Melbourne, Australia
 24/04/2005 9:00:39 PM


You're welcome.

TZ
Apr 24 2005
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:mrypw5e0gsvi.zf6thq5km4k2.dlg 40tude.net...

 On Sat, 23 Apr 2005 21:40:17 -0500, TechnoZeus wrote:


 "StarCrossed" <StarCrossed_member pathlink.com> wrote in message 
 news:d4ajh6$26kn$1 digitaldaemon.com...

 In article <d4ad7d$21ev$1 digitaldaemon.com>, TechnoZeus says...

And what of those cases where it is known but still not 
implemented?  Better to have a default.  If someone wants to 
make something not comparable, then they can override the 
default accordingly, I would think... just as Walter is talking 
about doing in the case of the argument being null.

This makes much more sense than to remove useful functionality 
from the language.


 total BS

 Do u program?


 That doesn't even deserve an answer, but.. yes.


 Well it just wasn't all that obvious. Thanks for clearing it up.


Now _that's_ comedy.

LOL

Derek, you're a gem. And what a tonic for the morning after the 
night before? :-)
Apr 24 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d46ii5$1cvv$1 digitaldaemon.com...
 

 Haven't been able to follow the debate the last few days. Has a
 consensus emerged?


 
 I was thinking about changing Object.opCmp to return false if the argument
 is null. I think that would satisfy most peoples' objections to it.


So every object would rank equally with null?  I'm not sure what sense 
that would make....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Apr 22 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stewart Gordon wrote:

 Walter wrote:

 
 I was thinking about changing Object.opCmp to return false if the 
 argument is null. I think that would satisfy most peoples'
 objections to it.


 
 So every object would rank equally with null?  I'm not sure what
 sense that would make....


Me neither. For opEquals, sure. But for opCmp ? Hmm...


The approach I took in a simple "String" class I made was:

	int opEquals(Object o)
	{
		if (this is o)
			return true;
		String string = cast(String) o;
		if (string is null)
			return false;

		return this.str == string.str;
	}

	int opCmp(Object o)
	{
		if (this is o)
			return 0;
		String string = cast(String) o;
		if (string is null)
			assert(0);

		return std.string.cmp(this.str, string.str);
	}

Based on how the same thing was being done in Java.
("cast" also takes care of the other's "instanceof")

--anders
Apr 22 2005