hi, thanks for the note!
> Diamond patterns only arise in multiple inheritance. We have no plans to > do multiple inheritance in BitC. i think things like the diamond issue arise whenever you have some form of mixing-in, not just m.i. if you do not have mixing in then you might have something like java single inheritance which, to be frank, sucks -- well, it sucks if there isn't really good support for delegation (avoiding boilerplate), at least. > So to answer your question: I think we have alternatives that fill some > of the gaps, but in general, no, I don't think that we have any grand > new inventions in the area of objects. What is really happening here is > that implementing this very relatively simplistic object system proves > to be much simpler than generalized existential types, and addresses all > of the use cases that concern us. i suspect/hope there don't need to be grand new ideas, only that one has to be careful about what one unleashes ;-). whatever you add to support objects will, realistically, get used in various ways by end-developers, and if your system doesn't help guide folks the right way / restrict folks from the wrong way, i feel it is doing your language + work to date a big disservice, that it can be a step backwards in the long run. $0.02 at best, sincerely. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
