Phil S (1) [Avatar] Offline
#1
Hi guys,

I've just been reading into the 2nd chapter where there are code samples, and I'm finding some of the terminology very grating to my sensibilities.

Fields marked final in java, or which are members of a scala case class constructor, are being referred to as "variables". But since their values cannot vary, they cannot be "variables". How about calling them "fields", "members" or "attributes" instead, so that mutability is not implied?

It gets worse, because in the java example they are actually called "Class variables". Many java developers I know would reserve this term for fields marked "static", i.e. Variables defined at the Class level rather than at the class instance, or object, level.

Another small point - I'm not sure it makes sense to recommend it as "good practice" to prefix the names of immutable classes in Java with the word "Immutable", if, as I assume, you're also going to be recommending that 99%+ of the classes in your application ought to be immutable! Good sense would suggest that you rather make an exception when naming the handful of "mutable" classes you might end up with.
Duncan DeVore (11) [Avatar] Offline
#2
Hi Phil,

This is great feedback and very much appreciated!

As you mention, the "variables" are really "values" and what we normally call them. I'm also seeing it used in some of the Java FP stuff, so I'm thinking "values" would be best. Does that sound good?

I like your idea of implied immutability and using the Mutable prefix when the class is mutable instead. We'll make both changes in the next release.

Cheers,



Phil S wrote:Hi guys,

I've just been reading into the 2nd chapter where there are code samples, and I'm finding some of the terminology very grating to my sensibilities.

Fields marked final in java, or which are members of a scala case class constructor, are being referred to as "variables". But since their values cannot vary, they cannot be "variables". How about calling them "fields", "members" or "attributes" instead, so that mutability is not implied?

It gets worse, because in the java example they are actually called "Class variables". Many java developers I know would reserve this term for fields marked "static", i.e. Variables defined at the Class level rather than at the class instance, or object, level.

Another small point - I'm not sure it makes sense to recommend it as "good practice" to prefix the names of immutable classes in Java with the word "Immutable", if, as I assume, you're also going to be recommending that 99%+ of the classes in your application ought to be immutable! Good sense would suggest that you rather make an exception when naming the handful of "mutable" classes you might end up with.