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?  

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?

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:

 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.

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