Fields vs. Properties

[Draco18s]

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.

[Draco18s]

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?

[Draco18s]

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

[Draco18s]

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.