View mode: basic / threaded / horizontal-split · Log in · Help
April 16, 2005
Re: Object.opCmp - about time we came to a decision
"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 16, 2005
Re: Object.opCmp - about time we came to a decision
"xs0" <xs0@xs0.com> wrote in message 
news:d3pg6t$1c8i$1@digitaldaemon.com...
>
>
> Matthew wrote:
>> "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?
>
> You can sort an Object[] without caring what the actual types are? 
> (of course, as long as all classes involved implement 
> opCmp(Object))

But sorting heterogeneous types is only meaningful in a subset of 
cases, and all those cases are accounted for in the alternative 
proposal.

I meant what advantages does the current approach have over the 
proposed approach? Since it has non-trivial disadvantages, there has 
to be advantages. Otherwise the language can be said to be just a 
mix of arbitrary illogical decisions, surely?
April 16, 2005
Re: Object.opCmp - about time we came to a decision
"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d3pcr2$19r3$1@digitaldaemon.com...
>
> "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?

I'd like to see a more complete description of what would change before 
making up my mind. If we just remove Object.opCmp obviously many things 
won't work (eg, aa's, sorting, dynamic array operations, maybe more) so what 
exactly won't work and what will have to change to get it to work? Redoing 
large chunks of the TypeInfo system isn't trivial IMO. Maybe I'm just being 
thick but I'd like to see more details.
April 16, 2005
Re: Object.opCmp - about time we came to a decision
In article <d3pq4b$1jhe$1@digitaldaemon.com>, Ben Hinkle says...
>
>I'd like to see a more complete description of what would change before 
>making up my mind. If we just remove Object.opCmp obviously many things 
>won't work (eg, aa's, sorting, dynamic array operations, maybe more) so what 
>exactly won't work and what will have to change to get it to work? Redoing 
>large chunks of the TypeInfo system isn't trivial IMO. Maybe I'm just being 
>thick but I'd like to see more details. 

Moving the methods to interfaces *almost* works, and the changes really aren't
too bad on the library side (I gave this a whirl with Ares--there's a branched
version on my website if you're interested).  But this approach also requires
changes to portions of DMD that aren't shipped in source form, so estimating
their scope is somewhat difficult.  Maybe someone with GDC experience could
chime in?


Sean
April 16, 2005
Re: Object.opCmp - about time we came to a decision
"Sean Kelly" <sean@f4.ca> wrote in message 
news:d3pqsk$1jsl$1@digitaldaemon.com...
> In article <d3pq4b$1jhe$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>I'd like to see a more complete description of what would change before
>>making up my mind. If we just remove Object.opCmp obviously many things
>>won't work (eg, aa's, sorting, dynamic array operations, maybe more) so 
>>what
>>exactly won't work and what will have to change to get it to work? Redoing
>>large chunks of the TypeInfo system isn't trivial IMO. Maybe I'm just 
>>being
>>thick but I'd like to see more details.
>
> Moving the methods to interfaces *almost* works, and the changes really 
> aren't
> too bad on the library side (I gave this a whirl with Ares--there's a 
> branched
> version on my website if you're interested).  But this approach also 
> requires
> changes to portions of DMD that aren't shipped in source form, so 
> estimating
> their scope is somewhat difficult.  Maybe someone with GDC experience 
> could
> chime in?

The interface would presumably be Comparable.opCmp(Comparable), correct? I 
thought the primary complaint against opCmp was that people would define a 
class Foo with Foo.opCmp(Foo) and expect it to work. With Comparable to get 
things to work one has to know about Comparable and write 
Foo.opCmp(Comparable) instead of Foo.opCmp(Object). Is this what the 
interfaces proposal is? I'm asking because I'm not sure exactly what the 
details of the proposal are. If that is the proposal then what are the 
benefits?
April 16, 2005
Re: Object.opCmp - about time we came to a decision
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message 
news:d3pq4b$1jhe$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message 
> news:d3pcr2$19r3$1@digitaldaemon.com...
>>
>> "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?
>
> I'd like to see a more complete description of what would change 
> before making up my mind. If we just remove Object.opCmp obviously 
> many things won't work (eg, aa's, sorting, dynamic array 
> operations, maybe more) so what exactly won't work and what will 
> have to change to get it to work? Redoing large chunks of the 
> TypeInfo system isn't trivial IMO. Maybe I'm just being thick but 
> I'd like to see more details.

Not at all. It's a great idea. I myself have only a semi-rigorous 
idea of what's to be involved. Kris is, I think, the top expert on 
this topic.

I think a proper discussion of what's involved is a great idea.

Kris, do you want to kick it off?
April 16, 2005
Re: Object.opCmp - about time we came to a decision
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message 
news:d3prvs$1kms$1@digitaldaemon.com...
>
> "Sean Kelly" <sean@f4.ca> wrote in message 
> news:d3pqsk$1jsl$1@digitaldaemon.com...
>> In article <d3pq4b$1jhe$1@digitaldaemon.com>, Ben Hinkle says...
>>>
>>>I'd like to see a more complete description of what would change 
>>>before
>>>making up my mind. If we just remove Object.opCmp obviously many 
>>>things
>>>won't work (eg, aa's, sorting, dynamic array operations, maybe 
>>>more) so what
>>>exactly won't work and what will have to change to get it to 
>>>work? Redoing
>>>large chunks of the TypeInfo system isn't trivial IMO. Maybe I'm 
>>>just being
>>>thick but I'd like to see more details.
>>
>> Moving the methods to interfaces *almost* works, and the changes 
>> really aren't
>> too bad on the library side (I gave this a whirl with 
>> Ares--there's a branched
>> version on my website if you're interested).  But this approach 
>> also requires
>> changes to portions of DMD that aren't shipped in source form, so 
>> estimating
>> their scope is somewhat difficult.  Maybe someone with GDC 
>> experience could
>> chime in?
>
> The interface would presumably be Comparable.opCmp(Comparable), 
> correct? I thought the primary complaint against opCmp was that 
> people would define a class Foo with Foo.opCmp(Foo) and expect it 
> to work. With Comparable to get things to work one has to know 
> about Comparable and write Foo.opCmp(Comparable) instead of 
> Foo.opCmp(Object). Is this what the interfaces proposal is? I'm 
> asking because I'm not sure exactly what the details of the 
> proposal are. If that is the proposal then what are the benefits?

I think there are two (or more) proposals here. My idea doesn't 
involve a particular interface, rather heterogeneity is supported as 
a natural consequence of the requirement for all types in the array 
(or whatever) to be related polymorphically.

I'm pretty sure what I proposed in March - "A proposal for a new, 
improved opCmp() [WAS: Round-up of the excuses for keeping 
Object.opCmp, and rebuttals to them]" 
(d0lsv5$1496$1@digitaldaemon.com) - still accurately represents my 
thoughts.

Matthew

P.S. Anyone advise on how to get a clickable message link from an 
entry in Outlook Express? I know it's done, because some of you do 
it. :-)
April 16, 2005
Re: Object.opCmp - about time we came to a decision
"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3psf3$1l16$1@digitaldaemon.com...
>
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
> news:d3pq4b$1jhe$1@digitaldaemon.com...
> >
> > "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
> > news:d3pcr2$19r3$1@digitaldaemon.com...
> >>
> >> "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?
> >
> > I'd like to see a more complete description of what would change
> > before making up my mind. If we just remove Object.opCmp obviously
> > many things won't work (eg, aa's, sorting, dynamic array
> > operations, maybe more) so what exactly won't work and what will
> > have to change to get it to work? Redoing large chunks of the
> > TypeInfo system isn't trivial IMO. Maybe I'm just being thick but
> > I'd like to see more details.
>
> Not at all. It's a great idea. I myself have only a semi-rigorous
> idea of what's to be involved. Kris is, I think, the top expert on
> this topic.

? Yer arse!


> I think a proper discussion of what's involved is a great idea.
>
> Kris, do you want to kick it off?

Okay. Here we are again at Wibbly Stadium, where the vast crowd of -- two -- 
are anxious for the match to begin ... Ref blows his whistle!

Match begins ~ Kris takes the centre-kick and ... passes the ball to
Matthew!

Seriously though. Sean just posted that he's actually tried the Interface
approach with Ares, so I suggest we take this conversation over there
instead. I'll happily weight in on the topic, but let's see what Sean has.

BTW; as far as resolutions go, I fully agree with Matthew's (earlier) take
on it. But the compiler would have to change for that to happen. If that's
kosher, then whoopee. Otherwise we have to look for an alternate. What Sean
is attempting appears to be one reasonable option.
April 16, 2005
Re: Object.opCmp - about time we came to a decision
"Kris" <fu@bar.com> wrote in message 
news:d3ptks$1lkj$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
> news:d3psf3$1l16$1@digitaldaemon.com...
>>
>> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
>> news:d3pq4b$1jhe$1@digitaldaemon.com...
>> >
>> > "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
>> > news:d3pcr2$19r3$1@digitaldaemon.com...
>> >>
>> >> "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?
>> >
>> > I'd like to see a more complete description of what would 
>> > change
>> > before making up my mind. If we just remove Object.opCmp 
>> > obviously
>> > many things won't work (eg, aa's, sorting, dynamic array
>> > operations, maybe more) so what exactly won't work and what 
>> > will
>> > have to change to get it to work? Redoing large chunks of the
>> > TypeInfo system isn't trivial IMO. Maybe I'm just being thick 
>> > but
>> > I'd like to see more details.
>>
>> Not at all. It's a great idea. I myself have only a semi-rigorous
>> idea of what's to be involved. Kris is, I think, the top expert 
>> on
>> this topic.
>
> ? Yer arse!
>
>
>> I think a proper discussion of what's involved is a great idea.
>>
>> Kris, do you want to kick it off?
>
> Okay. Here we are again at Wibbly Stadium, where the vast crowd 
> of -- two -- 
> are anxious for the match to begin ... Ref blows his whistle!
>
> Match begins ~ Kris takes the centre-kick and ... passes the ball 
> to
> Matthew!
>
> Seriously though. Sean just posted that he's actually tried the 
> Interface
> approach with Ares, so I suggest we take this conversation over 
> there
> instead. I'll happily weight in on the topic, but let's see what 
> Sean has.
>
> BTW; as far as resolutions go, I fully agree with Matthew's 
> (earlier) take
> on it. But the compiler would have to change for that to happen. 
> If that's
> kosher, then whoopee. Otherwise we have to look for an alternate. 
> What Sean
> is attempting appears to be one reasonable option.

Before we get into this, and potentially waste many more hours on 
challenging, enlightening, but eventually fruitless debate, I want 
to hear from Walter as to his _feeling_ on how close we are to 1.0, 
and therefore how amenable he's going to be to making significant 
language changes at this point. Otherwise, we really are just 
spending time we don't have for nothing more than a couple of 
chapters of "Imperfect D".

Walter, can you characterise your position? Specifically,
   1. Do you believe that there are any "serious flaws" in the D 
specification as it stands?
   2. If the answer is no, do you have a degree of certainty that 
is unlikely to be overridden by any observations any of us might 
make?
   3. If the answer to either 1 or 2 is yes, do you nonetheless 
have a need to expedite 1.0 despite any/all such "major flaws"?

Obviously, if we get (X, Yes, Y) or (X, Y, Yes), then there's no 
point having the debate.
April 16, 2005
Re: Object.opCmp - about time we came to a decision
>> The interface would presumably be Comparable.opCmp(Comparable), correct? 
>> I thought the primary complaint against opCmp was that people would 
>> define a class Foo with Foo.opCmp(Foo) and expect it to work. With 
>> Comparable to get things to work one has to know about Comparable and 
>> write Foo.opCmp(Comparable) instead of Foo.opCmp(Object). Is this what 
>> the interfaces proposal is? I'm asking because I'm not sure exactly what 
>> the details of the proposal are. If that is the proposal then what are 
>> the benefits?
>
> I think there are two (or more) proposals here. My idea doesn't involve a 
> particular interface, rather heterogeneity is supported as a natural 
> consequence of the requirement for all types in the array (or whatever) to 
> be related polymorphically.

Yeah - the C++-style of using compile-time generics instead of run-time 
dispatching (Object or Comparable) seems like the most reasonable 
alternative to me at the moment - though it would also probably disrupt the 
TypeInfo system the most. The TypeInfos are a way to get generic type hooks 
without using templates or overloading. My gut is leaning towards either 
keeping Object.opCmp dynamic binding or ditching that for compile-time 
binding. The Comparable solution seems like a fairly small modification of 
Object.opCmp that doesn't really give enough benefits over Object.opCmp. But 
that's just my gut feelings without knowing much of anything about the 
actual proposals and their impact...

> I'm pretty sure what I proposed in March - "A proposal for a new, improved 
> opCmp() [WAS: Round-up of the excuses for keeping Object.opCmp, and 
> rebuttals to them]" (d0lsv5$1496$1@digitaldaemon.com) - still accurately 
> represents my thoughts.

I'll try to hunt that down.

> Matthew
>
> P.S. Anyone advise on how to get a clickable message link from an entry in 
> Outlook Express? I know it's done, because some of you do it. :-)

That would be nice because I only know how to point to the forum page on the 
DigitalMars site and that only takes you to a particular message and not the 
thread.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home