I understand why it occurs, both the private and the final keyword affect the reference rather than the object. However, to quote someone else "That the value of a private field can be changed without a public setter implies that encapsulation is weak at best, and shouldn't be counted on to protect key values, even in combination with the final keyword." Even that comment, though, brings in the notion of a 'value' that's not an object.
My point initially was not about the code, but about the Java API doc that also claims attempting to change the value will result in a compile error. Although keywords affect references, the documentation states that it affects 'the value', which is at best ambiguous. There's inevitably a conflation of passing by value and passing by reference in Java by former C/C++ programmers, since it looks like PBV to a C/C++ programmer while always in fact being PBR. When copying syntax inverting the meaning of the syntax is counterproductive. There are also numerous issues around type erasure (mainly that it works for collections, even simple collections such as vectors, but not for arrays) and the resulting need for Java to allow invalid type casts in certain cases even though they can result in uncaught runtime exceptions. Since the fact that they are invalid is explicit in the API doc, that they are allowed because there's no other way to do it is problematic. Using lambdas or the streaming API within Java EE is another undocumented problem, or set of problems ( it was good fortune for me personally - when some software using the streaming API in an EE container consistently failed and the developer had no idea why, the company gave me the project I implemented it in Pharo, ☺ ). Oracle did at one point have a note on the Java EE 7 download page to the effect that Java EE 7 shouldn't be used with Java SE 8, but that was 'disappeared' when Java SE 7 was no longer supported and Java EE 7 was still the latest version. Since Java EE 8 is not even on the horizon, while SE 9 is due 'any minute now', I have to wonder if EE is simply dead. The requests from IBM, SAP and others to take over EE imply they at least suspect the same. I'd rather have no API documentation than documentation of the sort represented by the Java API doc. Not that I think it's all intentional, though perhaps the primitives and scalars that are in fact objects and collections may have been to muffle wailing from C/C++ programmers that the lack of primitives and scalars would kill performance. I suspect it's more often a result of unsuccessfully mode-switching, though, between the rules of the language you're implementing and those of the language you're implementing in, but that only makes the case for languages implemented in themselves stronger. Andrew -----Original Message----- Date: Fri, 13 Oct 2017 18:39:59 +0200 Subject: Re: [Pharo-users] Behold Pharo: The Modern Smalltalk To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Reply-to: Any question about pharo is welcome <pharo- us...@lists.pharo.org> From: Nicolai Hess <nicolaih...@gmail.com> Am 13.10.2017 5:50 PM schrieb "Andrew Glynn" <aglyn...@gmail.com>: I can't remember ever using API docs in any language, dynamic or not. They give you the method signatures, but if you have, say, methodX(int, int, String), how are you supposed to guess what ints and what String the method actually needs, Isn't this exactly what an apidoc is for? Additional documentation to describe the methods and arguments purpose. Maybe you have just seen poorly documented libraries? One of my favourite language fails can be reproduced by doing this: Declare a field private final in Java, initializing it either in the declaration or the constructor, and provide only a getter. Use the getter from another class and change the value of the local variable. Then use the getter again, but assign the value to a new local variable, and check the value. Maybe you should re-read about javas final keyword. It is not to meant making something immutable , you can just not reassign a new value. Java final != c++ const
