Fields vs. Properties

[Draco18s 2406]

This is mostly a question directed at @diesieben07. One of these days I'll figure out why a Field and a Property aren't the same thing. I certainly recognize the difference between these as a declaration:

public float value1;
public float value2 { get; set; }

The problem is that from outside the class (i.e. seeing only someObject.value1 and someObject.value2, both of which can be read and written), they behave / appear to behave the same way (ignoring the fact that value2 can be made read-only or write-only).

 

In trying to look up the difference, I got these three descriptions (thanks Stack Overflow):

 

Quote

• field

  • A data member of a class. Unless specified otherwise, a field is not static.
• property
  • Characteristics of an object that users can set.

(Eesh, how vague.)

Quote

Field is generally a private variable on an instance class. It does not mean there is a getter and a setter.

Property is the getter and setter combination.

Quote

Fields must be declared and initialized before they are used. Mostly for class internal use.

Properties can be changed by setter and they are exposed by getters.

 

Which...doesn't help (underscoring added for emphasis). The only seeming distinction is the fields are (usually?) protected* and properties are (always?) public.

Wait, if fields are protected, why mention that "unless specified, they aren't static"? Is a static field still protected!?

 

*protected here meaning to refer to either protected or private.

[diesieben07 7613]

I am not sure if there is a perfectly clear definition. However here is how I see it.

 

A property is a data-storing member of a class (when static) or an object (when non-static). There are several types of properties:

• "POJO-Style": private field plus getter/setter.
  • The field should not be accessed directly (even inside the same class), it is only used as underlying storage and encapsulated via getter and setter, which can add things like validation or lazy initialization.
  • Setter can be left out to make the property read-only.
  • Getter and setter can be given different visibilities to e.g. restrict writes to the class itself.
• Virtual property: Just a getter/setter
  • Value is computed on the fly whenever getter is accessed, possibly as a combination of other properties.
  • Same rules for getter and setter apply as above.
• Just a field
  • Usually not a good idea, since you cannot change semantics of getting and setting the property without breaking binary compability (you have to introduce getter and/or setter)
  • can be made read-only by making it final.

As you can see, property and field are orthogonal concepts. A field is a means to implement a property.

[Draco18s 2406]

4 minutes ago, diesieben07 said:

A field is a means to implement a property.

THAT is a definition I can work with.

 

I'll probably still refer to the value in object.value as a field or property interchangeably, though, as it comes down to an implementation detail inside the class that isn't relevant when talking about "that thing that is named 'value' and is part of the definition of the thing named 'object' "

 

9 minutes ago, diesieben07 said:

Usually not a good idea, since you cannot change semantics of getting and setting the property without breaking binary compability

How often does this come up when not dealing with ASM or [thing I don't have a word for, that is what Forge does, patching? (de)obfuscation?]?

It's a question that I cannot even attempt to analyze because the only Java work I've ever done has been for Minecraft via Forge.

That is, outside of Forge and Forge-like software, how often is binary compatibility an issue?

[diesieben07 7613]

1 minute ago, Draco18s said:

That is, outside of Forge and Forge-like software, how often is binary compatibility an issue?

All the time. Java projects often have a dependency tree the size of Texas (this is the dependency list of a current Spring Boot project I am working on, and I have barely started). If something updates and breaks binary compatibility, multiple types of excrement start hitting multiple types of propeller-based devices.

 

This is so much of a problem and nuisance, that Kotlin adds special syntax for properties.

[Draco18s 2406]

10 minutes ago, diesieben07 said:

All the time. Java projects often have a dependency tree the size of Texas (this is the dependency list of a current Spring Boot project I am working on, and I have barely started).

/me adds it to the "list of things to stay away from," keeping NPM company.

 

Also

Quote

If something updates and breaks binary compatibility, multiple types of excrement start hitting multiple types of propeller-based devices.

http://www.stilldrinking.org/programming-sucks

Edited March 6, 2018 by Draco18s

[diesieben07 7613]

3 minutes ago, Draco18s said:

/me adds it to the "list of things to stay away from," keeping NPM company.

The difference is that in the Java world this stuff usually works. NPM falls flat on it's face every other day.

 

4 minutes ago, Draco18s said:

http://www.stilldrinking.org/programming-sucks

Yup. Old but gold.

[Draco18s 2406]

23 minutes ago, diesieben07 said:

The difference is that in the Java world this stuff usually works. NPM falls flat on it's face every other day.

More like "Eh, I'm already not doing professional Java work, I'm now more incentivized not to." I'm sure it works Fine, but it's not "what I do" so I don't see a reason to make it "what I do."

I like modding Minecraft because there's a million billion things I don't have to worry about and I can make cool stuff.