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-
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