Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Usefulness of "final" (Was: Re: Inserting In a List) Date: Thu, 04 Apr 2013 22:53:18 +0200 Lines: 54 Message-ID: References: <19un43xj77bua.vw45l4e2wshi.dlg@40tude.net> <515cabb2$0$32111$14726298@news.sunsite.dk> <515cc192$0$32109$14726298@news.sunsite.dk> <515cc46b$0$32111$14726298@news.sunsite.dk> <515cc8e5$0$32109$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net lb4TD8SHXZ7weMXNz82GVwUuXoBUBcMunQwJxJMFzkzJ1P2kg= Cancel-Lock: sha1:ryTtUrUicvE4NkBwEtZEpR1mPRk= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 In-Reply-To: X-Antivirus: avast! (VPS 130404-1, 04.04.2013), Outbound message X-Antivirus-Status: Clean Xref: csiph.com comp.lang.java.programmer:23317 On 04.04.2013 20:08, markspace wrote: > On 4/4/2013 10:44 AM, Robert Klemme wrote: >> On 04.04.2013 18:47, markspace wrote: >>> On 4/4/2013 5:27 AM, Eric Sosman wrote: >>>> Perhaps the widely-held >>>> ideas about "immutable" are not those you share.) >>> >>> Well, if we're all using different definitions of a term, talking about >>> it is pretty tough. Immutability is defined correctly in the JLS, at >>> least for Java. I think it would be most useful to use that term. >> >> If it was I'd guess the terms "mutable" or "immutable" would surely show >> up in the index, but they don't - opposed to "final" which has several >> entries: >> >> http://docs.oracle.com/javase/specs/jls/se7/html/jls-0-index.html >> >> No, the JLS does not define "immutable" - it just mentions it. > > OK then, so what definition would this group like to use to describe the > kinds of objects the JLS talks about in Section 17.5? I'd go with the heading of that section: "final Field Semantics" - and it's not primarily about "objects" but about "final fields" or put differently: final object references. That section defines semantics of final fields and just mentions "immutable objects" as an example of a concept that may be created by (properly) using final fields. Immutability (or constness) of an object is a tricky concept. There are at least two useful and totally reasonable definitions: 1. State (as in: bit patterns in memory) of a const object never changes. 2. The user of a const object can never observe any state changes; put differently: all methods of a constant object always return the same results for the same inputs. You can also see that from the development C++ took: keyword "mutable" was introduced later to allow state changes of instances declared "const"; this helps implementing lazy initialization and caching schemes. Other than for type 1 constness compiler checks for type 2 constness are significantly more complicated - if they are possible at all: call a function in a method and all bets are off. Without access to the function's source (or at least bytecode in Java) a compiler cannot determine whether type 2 constness is observed in all circumstances. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/