View mode: basic / threaded / horizontal-split · Log in · Help
April 18, 2005
Re: Object.opCmp - about time we came to a decision
xs0 wrote:
<snip>
> To me, not defining an opEquals is basically stating you won't compare 
> objects with ==. IMHO, if you want to compare references, you have is, 
> and if you're writing templates that use ==, you should define opEquals 
> anyway.
<snip>

And if I want to use a template from someone else's library wrote with a 
class from someone else's library...?

Stewart.
-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
April 18, 2005
Re: Object.opCmp - about time we came to a decision
Stewart Gordon wrote:
> xs0 wrote:
> <snip>
> 
>> To me, not defining an opEquals is basically stating you won't compare 
>> objects with ==. IMHO, if you want to compare references, you have is, 
>> and if you're writing templates that use ==, you should define 
>> opEquals anyway.
> 
> <snip>
> 
> And if I want to use a template from someone else's library wrote with a 
> class from someone else's library...?
> 
> Stewart.

Well, I'm sure that argument can be used for any given implementation of 
opEquals.. Nothing will fit all possible requirements..

I don't know, extend the class and implement opEquals, or, if its a 
hierarchy, wrap the reference in a struct that has opEquals, or change 
the template (you can only use it in source form, so you must have 
source)? I guess the right way to write templates is "a is b || a==b" 
anyway, because it handles all cases of equality, regardless of what is 
defined where..

Anyway, it was just an idea, no need to argue about it - if you don't 
think it would be useful to you, it probably wouldn't..


xs0
April 18, 2005
Re: Object.opCmp - about time we came to a decision
>>> I meant all I know how to do is this: 
>>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/6809 How
>>> can I get a link to the whole thread instead of just a message in the 
>>> thread?
>>
>> Oops, I misunderstood. I don't think I've seen anyone do that (maybe
>> it doesn't work for me since I use Thunderbird). Would it show up in
>> a newsreader or a web-browser?

I agree - I don't think it is possible either, but I figured I'd ask since 
many people on this list can run a forum site in their sleep and might know 
a trick to get the thread link. I only mentioned it because Matthew 
innocently asked the question about how to get OE to produce links - which I 
don't know how to do either. When I want to reference a message I have to go 
fire up the dmd web site and find the message and grab the URL.

>> Or do you mean one of the archive pages, such as 
>> http://www.digitalmars.com/d/archives/digitalmars/D/13965.html?

no.

>> There's a separate main page for each newsgroup (but Walter hasn't
>> run his update process in a while, so not all of the newsgroups even
>> have a page yet):
>
> Man, we should collect money to give him a Linux box. ;-)
> They do stuff like that by themselves.

I already have a Linux box - or more accurately I made my Windows box 
dual-boot. I flip back and forth about my preferred boot system. Some months 
I wind up working on Linux more, sometimes Windows more.

>> http://www.digitalmars.com/d/archives/digitalmars/D/index.html 
>> http://www.digitalmars.com/d/archives/digitalmars/D/dtl/index.html 
>> http://www.digitalmars.com/d/archives/digitalmars/D/bugs/index.html 
>> http://www.digitalmars.com/d/archives/D/gnu/index.html 
>> http://www.digitalmars.com/d/archives/index.html

yup. I'm aware of those. I often search them for reference links.
April 18, 2005
Re: Object.opCmp - about time we came to a decision
Ben Hinkle wrote:
>>> There's a separate main page for each newsgroup (but Walter
>>> hasn't run his update process in a while, so not all of the
>>> newsgroups even have a page yet):
>> 
>> Man, we should collect money to give him a Linux box. ;-) They do
>> stuff like that by themselves.
> 
> I already have a Linux box - or more accurately I made my Windows box
>  dual-boot. I flip back and forth about my preferred boot system.
> Some months I wind up working on Linux more, sometimes Windows more.

I meant get a Linux box for Walter, so he didn't have to _remember_ to 
update the newsgroups every time.

:-)
April 18, 2005
Re: Object.opCmp - about time we came to a decision
On Mon, 18 Apr 2005 08:51:47 -0400, Ben Hinkle <ben.hinkle@gmail.com>  
wrote:
>>>> I meant all I know how to do is this:
>>>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/6809 How
>>>> can I get a link to the whole thread instead of just a message in the
>>>> thread?
>>>
>>> Oops, I misunderstood. I don't think I've seen anyone do that (maybe
>>> it doesn't work for me since I use Thunderbird). Would it show up in
>>> a newsreader or a web-browser?
>
> I agree - I don't think it is possible either, but I figured I'd ask  
> since
> many people on this list can run a forum site in their sleep and might  
> know
> a trick to get the thread link. I only mentioned it because Matthew
> innocently asked the question about how to get OE to produce links -  
> which I
> don't know how to do either. When I want to reference a message I have  
> to go
> fire up the dmd web site and find the message and grab the URL.

I just grab the first part of the url i.e.
http://www.digitalmars.com/drn-bin/wwwnews?

add the newsgroup name
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/

add the article id (I get this from the headers of the message I want to  
reference, i.e. your message to which I replied has "Xref:  
	digitalmars.com digitalmars.D:21910" giving me
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/21910

It would be nice if the client did all this work for me, it could do from  
"http://www.digitalmars.com/drn-bin/wwwnews?" and the Xref header.

Regan
April 19, 2005
Re: Object.opCmp - about time we came to a decision
Georg Wrede wrote:
> Ben Hinkle wrote:
> 
>>>> There's a separate main page for each newsgroup (but Walter
>>>> hasn't run his update process in a while, so not all of the
>>>> newsgroups even have a page yet):
>>>
>>>
>>> Man, we should collect money to give him a Linux box. ;-) They do
>>> stuff like that by themselves.
>>
>>
>> I already have a Linux box - or more accurately I made my Windows box
>>  dual-boot. I flip back and forth about my preferred boot system.
>> Some months I wind up working on Linux more, sometimes Windows more.
> 
> 
> I meant get a Linux box for Walter, so he didn't have to _remember_ to 
> update the newsgroups every time.

I don't expect Walter to update the archives every day, but once a month 
would be nice. ;)

> 
> :-)


-- 
jcc7
http://jcc_7.tripod.com/d/
April 20, 2005
Re: Object.opCmp - about time we came to a decision
Technically, I can't think of any possible type that would be "unorderable" although it is sometimes good to distinguish between an ordering that is implicit in the nature of the intended representation, and an ordering that is derived from the internal representation used to store the data rather than the nature of what that data was meant to represent.

In other words, the concepts of ">" and "<" could be used to predictably sort items for the sake of being able to have them at least temporarily in a predictable order even if that order is unrelated to the nature of the items being sorted.  For example, if an enum type assigns an integer value internally to each of it's "unordered" values, then an ordered comparison will have predictable results at least within a limited context and scope.  For example, true>false may not give the same results for different implementations, but would give the same results each time it occurrs within a given implementation as long as the internal values of "true" and "fales" are not altered.

My point is, there are many grey areas in the concept of ordered or unordered, and some of them may be useful to have access to by allowing the underlying "bit patterns" to be accessed, set, compared, etc., independant of the nature of the data that those bit patterns are intended to represent.  One good example of this is the idea of using the bit patterns of reference types in default comparison and assignment operations.

TZ


"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:d400kv$m57$1@digitaldaemon.com...
> Walter wrote:
> <snip>
> > You're right. At the moment, it is not practical to create a class that
> > wraps a float because the comparisons won't be able to handle unordered
> > values.
> <snip>
>
> Moreover, unordered values can't be used in binary search trees and the
> like (one thing Java uses orderings for).  But maybe it's possible to
> support partially ordered types in such a way that they'll be
> distinguishable from totally ordered types.  And maybe even implement a
> topological sort on partial orderings.
>
> Stewart.
>
> -- 
> My e-mail is valid but not my primary mailbox.  Please keep replies on
> the 'group where everyone may benefit.
April 20, 2005
Re: Object.opCmp - about time we came to a decision
Actually, the natural extension of your pointing out that you are not sure how many people are aware of that is exactly why I think it's important to have such things work "across the board" whenever possible.  It makes the unknown into something versitile and predictable.  In other words, we can know that something is (or at least should be) possible, without ever having tried it... or even having heard of it.

TechnoZeus

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d3p354$1252$1@digitaldaemon.com...
> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message
> news:d3m7do$1bdk$1@digitaldaemon.com...
> > It's about time we finally made up our mind what we're going to do with
> > Object.opCmp.
>
> I'm not sure how many people know this but you can compare dynamic arrays.
> For arrays of objects it winds up calling Object.opCmp. So removing
> Object.opCmp would make array comparison more complex since presumably the
> compiler would have to check if it was legal or not. Not that I'm arguing
> opCmp should stay - just that any argument to remove it needs to look at all
> the places it is used, propose alternatives and objectively assess the pros
> and cons.
>
> int main() {
>     int[] x,y;
>
>     x = new int[5];
>     y = new int[7];
>     printf("shorter %d %d %d\n",x<y, x == y, x is y);
>
>     y = new int[5];
>     printf("equal   %d %d %d\n",x<y, x == y, x is y);
>
>     x[3] = 10;
>     printf("greater %d %d %d\n",x<y, x == y, x is y);
>
>     return 0;
> }
>
> prints
>
> shorter 1 0 0
> equal   0 1 0
> greater 0 0 0
>
> Substitute a class for 'int' above and it continues to work.
>
>
April 20, 2005
Re: Object.opCmp - about time we came to a decision
What you are calling a disease, in this case, I think of as a useful and powerful feature.  Perhaps that's why people would rather treat it than cure it.  Why fix it if it's not broken?

TZ

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d3pn7e$1hth$1@digitaldaemon.com...
>
> "pragma" <pragma_member@pathlink.com> wrote in message
> news:d3pfrv$1c70$1@digitaldaemon.com...
> > In article <d3pcr2$19r3$1@digitaldaemon.com>, Matthew says...
> >>
> >>
> >>"Ben Hinkle" <bhinkle@mathworks.com> wrote in message
> >>news:d3p9qh$17hr$1@digitaldaemon.com...
> >>>> 2. Leave the current DMD behaviour in, and document it
> >>>> properly.
> >>>
> >>> I would add 2a: leave it in, document it and add a warning to
> >>> dmd
> >>> and dlint for classes that define an opCmp that shadows
> >>> Object.opCmp.
> >>> In fact a general warnings about shadowing member functions in
> >>> base classes should say "Foo.opCmp(Foo) shadows
> >>> Object.opCmp(Object)". For the common case of Object.opCmp it
> >>> should give a nicer warning that should say something like
> >>> "Foo.opCmp(Foo) shadows Object.opCmp(Object). Consider defining
> >>> Foo.opCmp(Object) for associative arrays, sorting and other
> >>> uses".
> >>
> >>But what's the attraction with addressing the symptoms of a
> >>disease,
> >>when we can prevent the disease?
> >>
> >>I'm not being sarcastic, I really want to know why people prefer
> >>this approach? Does it have _any_ advantages?
> >
> > It requires zero compiler changes.
>
> Sure. But is that a good reason, in a pre-1.0 language that aims to
> avoid making the mistakes of its predecessors?
>
> What's wrong with change at this stage?
>
>
>
April 20, 2005
Re: Object.opCmp - about time we came to a decision
"Sean Kelly" <sean@f4.ca> wrote in message news:d3phhq$1dlj$1@digitaldaemon.com...
> In article <d3pg6t$1c8i$1@digitaldaemon.com>, xs0 says...
> >>
> >> I'm not being sarcastic, I really want to know why people prefer
> >> this approach? Does it have _any_ advantages?
> >
> >You can sort an Object[] without caring what the actual types are? (of
> >course, as long as all classes involved implement opCmp(Object))
>
> But is this an advantage?  I've personally never found a reason to compare to
> entirely unrelated types.  Type safety is a Good Thing.
>
> Sean
>
>

Yes, there are huge advantages to it in specific cases where that is what the software designer wants to do.  Never assume that your not having found something precludes it's existance.  That's the beauty of generic functionality.  In addition to being applicable to a wide range of known situations, it's applicable to things nobody's even thought of yet.

Besides, removing it would only increase the work that the compiler would have to perform in some cases and increase the work that the programmer would have to perform in other cases.  There are no cases where removing such an ability would reduce the amount of coding necessary to produce an algorithm that would perform a specific task, and removing such an ability would commonly have a negative impact on performance while rarely if ever having a positive impact.

TZ
3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home