Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: =?UTF-8?B?Sm9zaHVhIENyYW5tZXIg8J+Qpw==?= Newsgroups: comp.lang.java.programmer Subject: Re: Alternatives languages on the JVM: which one or is there no alternative? Date: Wed, 27 Nov 2013 23:07:50 -0600 Organization: A noiseless patient Spider Lines: 35 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 28 Nov 2013 05:07:58 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="c6716b6a473a9c60ebbf78e095cba276"; logging-data="2287"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/A7WaYjcNogXTMAgXhJ9DEE1vivtwEnEU=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Thunderbird/26.0 In-Reply-To: Cancel-Lock: sha1:q0N4JStosuYgOFJf2Ksv44NiQzM= Xref: csiph.com comp.lang.java.programmer:26650 On 11/26/2013 11:13 PM, Volker Borchert wrote: > You still have an extra two-word object header, and you cannot use > WeakReference directly if you want the Foo to act on the > reference being cleared by garbage collection. These 24 extra bytes > hurt if you are doing low-level stuff and expect some tens or > hundreds of thousands of Foo. And you think multiple inheritance has no costs? The moment you allow multiple inheritance of implementations, you permit the so-called "diamond problem." The diamond problem has three solutions: 1. There are multiple copies of some fields. 2. Offsets to a particular named field are dependent on object instances, not on classes/class hierarchies. 3. Casting up or down a tree requires recomputing offsets on a per-object instance basis, not a per-class basis. The first case only affects classes that are involved in the diamond problem, but the effects are so egregiously awful (in the case where data is actually present) that it is prudent to outlaw it from happening. The latter two cases impose a performance penalty on the entire program, even if the diamond problem never arises: you're paying for what you don't use. Multiple inheritance is a seductive call. There are very, very, very few times where it is actually proper--recall that inheritance, at least as Java is concerned, is meant to model an "is-a" relationship, not a "has-a" relationship. Since inheritance is an indelible part of the public contract of a class in Java, the "is implemented in terms of" relationship is supposed to be handled via composition (cf., Effective Java). Let the JIT and the optimizer work through the overhead; premature optimization, after all, is the root of all evil. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth