That’s just not true, you can have a completely value-based language without OOP that still doesn’t leak implementation details of the values, while also supporting UDTs.

▲

jstimpfle 7 hours ago | parent [-]

OOP isn't just about values vs objects. Yes, the idea that everything needs identity is a big part of the problem. But another big problem is the idea that the implementation and representation of types should be hidden by default. The mindset that there isn't a known and useful data representation for a given type. That everything is done by methods parameterized by a type. It's a misguided idea. There is a place for objects and implementation hiding. But the idea that this should be done on a type granularity is a complete and utter failure.

To see why, consider that to do any useful work, data from different objects (also from different types) has to be combined. To be able to do that in the OOP framework, the encapsulation has to be unwrapped. That's why Java code is littered with getters and setters that don't do any useful work at all, they just make it too painful to get any real work done.

Again, there is a place for objects and implementation hiding, but it's at the highest levels of an architecture where different components get integrated.

▲

tsimionescu 3 hours ago | parent | next [-]

All of this would be valid, except that value classes still pretend that their fields can be private.

This also has huge implications in a language that emphasises dynamic loading like Java. And it also flies in the face of all of the pretenses that ABI compatibility is sacrosanct and no feature that breaka it can be considered, that the design team often touts.

	▲	usrusr 2 hours ago \| parent [-]
		Why pretend? "private" on value types just means nothing to see here except when you happen to be one of the functions conveniently namespaced with the struct. But I'd say that GP's complaint about inequality leaking makes no sense anyways, because what could be more unequal than different implementation, or different internal state implying different behavior down the line? The public subset isn't some arbitrary interface that could have different implementations. And even then, "equals under interface I1" would have to be considered a very special type of "equality", not the general case.

▲

rowls66 3 hours ago | parent | prev [-]

There is no requirement in the Java language to use getters and setters.

	▲	jstimpfle 3 hours ago \| parent [-]
		But why are there so many of them?