All right, all right! Interim decision regarding qualified Object methods

[deadalnix]

On 12/07/2012 11:51, Jonathan M Davis wrote:
> 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

I'd advocate that rely on Object isn't a wise idea anyway. I've worked 
quite a lot in java and it is a recurring problem (mostly because of the 
way generic is implemented). The problem we encountered here are another 
confirmation of that.

We have much greater metaprogramming capabilities than Java, and it 
seems like a good idea to leverage that.