2017-10-13 22:04 GMT+02:00 Andrew Glynn <aglynn42@gmail.com>:
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.
and who did you quote ?
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.
I can not see what is wrong here. You are problably confused by - the value of a *variable* - and the value an *object* represents (its object state) the first can not be changed for a final variables the last can only be preserved, if the object is immutable.
There are also numerous issues around type erasure
... this seems a bit off topic
I'd rather have *no* API documentation than documentation of the sort represented by the Java API doc.
I think a java api doc like documentation would help. For newcomers, that not yet know ( or know how to find) the in-image help. And even so we can easily browse our code with comments and class comments, an API-doc could provide the help from a different view (group by collaboration rather then by class hierarchy or packages), give an "overall" view or provide additional code examples.
Not that I think it's all intentional, though perhaps the primitives and scalars that are in fact objects
How are java primitives "in fact" objects ? They are "in fact" primitives. This is different from smalltakl where some *objects* like Smallinteger are implemented as primitives (or immediates) but still objects on the (smalltalk) code level.
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- users@lists.pharo.org> From: Nicolai Hess <nicolaihess@gmail.com>
Am 13.10.2017 5:50 PM schrieb "Andrew Glynn" <aglynn42@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