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

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

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

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

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

"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.)

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. :-)

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. :-)

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.

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.