April 16, 2005
"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
"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
"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
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
"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
"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
"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
"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
"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
>> 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.