2017-10-13 22:04 GMT+02:00 Andrew Glynn <aglyn...@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- > 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 > > > >
