On 7/12/2012 12:59 AM, Jonathan M Davis wrote:
> So, I think that it's probably a solid way to go, and it does appear to solve
> the const issues that we've been having quite nicely, but it also appears to
> break a number of things which have worked for some time, and we're going to
> have to figure out how we're going to deal with that, even if it's only
> providing a good deprecation path.

A main motivation for going this route is to avoid breaking existing code.

On Thursday, July 12, 2012 02:43:09 Walter Bright wrote:
> On 7/12/2012 12:59 AM, Jonathan M Davis wrote:
> > So, I think that it's probably a solid way to go, and it does appear to solve the const issues that we've been having quite nicely, but it also appears to break a number of things which have worked for some time, and we're going to have to figure out how we're going to deal with that, even if it's only providing a good deprecation path.
> 
> A main motivation for going this route is to avoid breaking existing code.

Except that it's _guaranteed_ to break code, because anything which relies on Object having opEquals, opCmp, toHash, or toString is going to break. We can provide an appropriate deprecation path to ease the transition, but this _will_ break code.

- Jonathan M Davis

On Thursday, 12 July 2012 at 08:59:46 UTC, Don Clugston wrote:
> On 12/07/12 06:15, Andrei Alexandrescu wrote:
>> Required reading prior to this: http://goo.gl/eXpuX
>>
>> You destroyed, we listened.
>>
>> I think Christophe makes a great point. We've been all thinking inside
>> the box but we should question the very existence of the box. Once the
>> necessity of opCmp, opEquals, toHash, toString is being debated, we get
>> to some interesting points:
>>
>> 1. Polymorphic comparisons for objects has problems even without
>> considering interaction with qualifiers. I wrote quite a few pages about
>> that in TDPL, which add to a lore grown within the Java community.
>>
>> 2. C++ has very, very successfully avoided the necessity of planting
>> polymorphic comparisons in base classes by use of templates. The issue
>> is template code bloat. My impression from being in touch with the C++
>> community for a long time is that virtually nobody even talks about code
>> bloat anymore. For whatever combination of industry and market forces,
>> it's just not an issue anymore.
>>
>> 3. opCmp, opEquals, and toHash are all needed primarily for one thing:
>> built-in hashes. (There's also use of them in the moribund .sort
>> method.) The thing is, the design of built-in hashes predates the
>> existence of templates. There are reasons to move to generic-based
>> hashes instead of today's runtime hashes (such as the phenomenal success
>> of templated containers in C++), so it can be argued that opCmp,
>> opEquals, and toHash exist for reasons that are going extinct.
>>
>> 4. Adding support for the likes of logical constness is possible, but
>> gravitates between too lax and onerously complicated. Walter and I don't
>> think the aggravation is justified.
>>
>> There are of course more angles and considerations. Walter and I
>> discussed such for a while and concluded we should take the following
>> route:
>>
>> 1. For the time being, rollback the changes. Kenji, could you please do
>> the honors? There's no need to undo everything, only the key parts in
>> object.d. Apologies for having to undo your work!
>>
>> 2. Investigate a robust migration path from the current use of opCmp,
>> opEquals, toHash (we need to also investigate toString) to a world in
>> which these methods don't exist in Object. In that world, associative
>> arrays would probably be entirely generic. Ideally we should allow
>> existing code to still work, while at the same time fostering a better
>> style for new code.
>>
>>
>> What say you?
>>
>> Andrei
>
> Well:
> * having opCmp() defined for all objects is just plain weird.
> * toString() is a poor design anyway.
>
> But we'd need to be very careful, this is a very disruptive change.

I don't find them that weird, because many OO languages do have them.

But I am fine with the design that feels better in D.

--
Paulo

On 12/07/12 12:00, Paulo Pinto wrote:
> On Thursday, 12 July 2012 at 08:59:46 UTC, Don Clugston wrote:
>> On 12/07/12 06:15, Andrei Alexandrescu wrote:
>>> Required reading prior to this: http://goo.gl/eXpuX
>>>
>>> You destroyed, we listened.
>>>
>>> I think Christophe makes a great point. We've been all thinking inside
>>> the box but we should question the very existence of the box. Once the
>>> necessity of opCmp, opEquals, toHash, toString is being debated, we get
>>> to some interesting points:
>>>
>>> 1. Polymorphic comparisons for objects has problems even without
>>> considering interaction with qualifiers. I wrote quite a few pages about
>>> that in TDPL, which add to a lore grown within the Java community.
>>>
>>> 2. C++ has very, very successfully avoided the necessity of planting
>>> polymorphic comparisons in base classes by use of templates. The issue
>>> is template code bloat. My impression from being in touch with the C++
>>> community for a long time is that virtually nobody even talks about code
>>> bloat anymore. For whatever combination of industry and market forces,
>>> it's just not an issue anymore.
>>>
>>> 3. opCmp, opEquals, and toHash are all needed primarily for one thing:
>>> built-in hashes. (There's also use of them in the moribund .sort
>>> method.) The thing is, the design of built-in hashes predates the
>>> existence of templates. There are reasons to move to generic-based
>>> hashes instead of today's runtime hashes (such as the phenomenal success
>>> of templated containers in C++), so it can be argued that opCmp,
>>> opEquals, and toHash exist for reasons that are going extinct.
>>>
>>> 4. Adding support for the likes of logical constness is possible, but
>>> gravitates between too lax and onerously complicated. Walter and I don't
>>> think the aggravation is justified.
>>>
>>> There are of course more angles and considerations. Walter and I
>>> discussed such for a while and concluded we should take the following
>>> route:
>>>
>>> 1. For the time being, rollback the changes. Kenji, could you please do
>>> the honors? There's no need to undo everything, only the key parts in
>>> object.d. Apologies for having to undo your work!
>>>
>>> 2. Investigate a robust migration path from the current use of opCmp,
>>> opEquals, toHash (we need to also investigate toString) to a world in
>>> which these methods don't exist in Object. In that world, associative
>>> arrays would probably be entirely generic. Ideally we should allow
>>> existing code to still work, while at the same time fostering a better
>>> style for new code.
>>>
>>>
>>> What say you?
>>>
>>> Andrei
>>
>> Well:
>> * having opCmp() defined for all objects is just plain weird.
>> * toString() is a poor design anyway.
>>
>> But we'd need to be very careful, this is a very disruptive change.
>
> I don't find them that weird, because many OO languages do have them.

Really? I find that incredible. Ordered comparisons <, > don't even make sense for many mathematical objects!
You can't even define opCmp for a float.

Object f = new FtpConnection;
Object e = new Employee("Bob");
if (f > e)  // Huh???

Andrei Alexandrescu:

> What say you?

It's an interesting proposal, and I like it in general.

In D the C++-improved template system and the Java-copied OOP are partially a duplication, they sometimes offer two different ways to do similar things. I think this proposal reduces this duplication a bit.

This whole discussion comes mostly from fixing an old Bugzilla bug. What other important bugs are open that risk requiring significant changes in D? I suggest to look for such breaking bug fixes asap, instead of waiting 2+ more years to find some bug that requires more important D changes to be fixed :-)

Bye,
bearophile

Andrei Alexandrescu:

> The issue is template code bloat. My impression from being in touch with the C++ community for a long time is that virtually nobody even talks about code bloat anymore. For whatever combination of industry and market forces, it's just not an issue anymore.

There is no proof that template bloat won't be a problem in D (I remember the first version of the D Objective-C bridge failing because of code bloat, the second version seems to require changes in the D language). And it seems L1 code caches of CPUs aren't growing a lot (so I suggest to not ignore having lot of code to swap in and out of those 32 kbytes).

So maybe it will be useful to introduce in D some means to attack the code bloat problem from several sides at the same time.

Some time ago I have suggested one of such weapons, the @templated() that allows to select what parts of a struct/class are templated regarding to what template arguments (it's a refinement of an idea of Stroustrup).

Another weapon to attack the problem is introducing in the DMD back-end an optimization (already present in LLVM, but I think not used on default), merging of functions with the same body (leaving just a jump as the body of the removed function, to keep their function pointers distinct).

Bye,
bearophile

> "bearophile"  wrote in message news:xrbtkoercscroxgtodcu@forum.dlang.org...
>>Andrei Alexandrescu:
>>
>> What say you?
>
>It's an interesting proposal, and I like it in general.
>
>In D the C++-improved template system and the Java-copied OOP are partially a duplication, they sometimes offer two different ways to do similar things. I think this proposal reduces this duplication a bit.
>
>This whole discussion comes mostly from fixing an old Bugzilla bug. What other important bugs are open that risk requiring significant changes in D? I suggest to look for such breaking bug fixes asap, instead of waiting 2+ more years to find some bug that requires more important D changes to be fixed :-)
>
>Bye,
>bearophile

Specially because  not all breaking changes are possible, otherwise one
has something like Python 3. Which is a very good improvement, but leads
to resistance to upgrade.

On the other hand, these type of continuous changes lead to FUD about D
not being stable and usable for projects.

So I guess a kind of balance needs to be achieved.

--
Paulo

> Another weapon to attack the problem is introducing in the DMD back-end an optimization (already present in LLVM, but I think not used on default), merging of functions with the same body (leaving just a jump as the body of the removed function, to keep their function pointers distinct).

Why not drop that requirement? What is the use case of different function pointers for different but equivalent functions? Does anyone depend on this?

Tobias Pankrath:

> Why not drop that requirement? What is the use case of different function pointers for different but equivalent functions? Does anyone depend on this?

It's a requirement that comes from C specs, and I don't know why C was designed that way, as usual I am not expert enough. I prefer to not change the semantics of D over C unless there is an important reason, especially when I don't know/understand the rationale of the original C design :-)

Bye,
bearophile

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:thmrfdsenkmtasilhocp@forum.dlang.org...
>
> Another weapon to attack the problem is introducing in the DMD back-end an optimization (already present in LLVM, but I think not used on default), merging of functions with the same body (leaving just a jump as the body of the removed function, to keep their function pointers distinct).

This should be in the linker, not the backend.  Keeping function pointers distinct is probably not that important, using shared libraries/dlls can (supposably) already break them.