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.
