The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

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.