Data Classes for Java • Hacker News Board

Re: Data Classes for Java

#181

Post by FollowSteph3 » Thu, Nov 02, 2017, 12:51 PM UTC

qw wrote: post #148

FollowSteph3 wrote: post #118

Earlier quoted context omitted.

Let me give a concrete example from my past. We had a public API of POJO domain objects that could be used to render templated files, think string replace. It worked great until one day someone had a special character that caused it all to fail. How do you fix this? Ask all customers to clean their values? Good luck with that!! However from our side we just added the code to clean the output, escape the special chara…

What use did you have from the getter? That seems like a situation where you would only change the setter (or a builder if you use that pattern).

In fact you may want to edit the getter because who says you’re the one who controls the setter. As in there may be more than one way to set the value ;)

Re: Data Classes for Java

#182

Post by bunderbunder » Thu, Nov 02, 2017, 1:15 PM UTC

willtim wrote: post #175

lmm wrote: post #165

Earlier quoted context omitted.

One of the earliest use cases for implicits is that in Java most types are erased but Arrays aren't, so you can't instantiate an Array in a generic method without having some way to pass the concrete type through.

I do not see why this problem cannot be solved by a compiler rather than a language feature. The type is statically known. It may require additional metadata alongside class files for separate compilation, but I don't see this as a big issue.

Scala needs to interoperate with other Java languages, and there is no platform-wide spec for supplying such metadata.

Even if there were, it couldn't be statically known at compile time in the case where a library written in Scala is being called by code that was written at a later date.

And even without that consideration, types still cannot be statically known in cases where you're being handed objects whose type is not determined until run time. Which happens all the @$#% time in Scala, due to its use of algebraic data types.

So, e.g., Java's run-time has no real way of expressing the type `Option>`. You can declare it and get some compile-time checking, but that's all erased before the final bytecode is generated. There's no such thing as `Option>.class`. This really limits what you can do with generic code. Scala added its own parallel type tag system to get around that. It's weird as heck and only really usable from other Scala code, though.

Re: Data Classes for Java

#183

Post by unholiness » Thu, Nov 02, 2017, 1:17 PM UTC

geophile wrote: post #66

mikeash wrote: post #30

Earlier quoted context omitted.

I like Swift's approach to this. (I'm sure other languages do it too, that's just the one I know that does this.) If you write a property (what other languages might call a "field") then by default it's a stored property, i.e. it's backed by a bit of memory in the object. If you need to take actions on changes, you can implement a willSet or didSet handler to do so. If you need to change how the value is stored and r…

I really, really dislike Swift's approach. get/set/willSet/didSet -- so much complication to preserve the illusion that you are operating on a field when you are actually doing no such thing. Why is this desirable? It reminds me of a class of C++ footguns where some innocuous code is actually invoking member functions due to operator overloading. I think that Java got this one right. (I do not at all like the cargo c…

GP was referring to the feature that getters/setters are invoked with property access. Swift's didSet/willSet distinction is unrelated to this feature. ES6 JavaScript, for instance, has this feature with just get/set methods.

In Java (and JS) there's a separate, all-knowing garbage collector, while swift is reference counted. In an ARC runtime, the didSet/willSet distinction avoids explicit calls to release the object, which is pretty clearly a good thing on the programmer's end. You can debate whether the benefits of full garbage collectors outweigh their performance characteristics, but given ARC, the didSet/willSet distinction definitely makes sense.

Re: Data Classes for Java

#184

Post by josteink » Thu, Nov 02, 2017, 1:27 PM UTC

HumanDrivenDev wrote: post #2

... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…

> If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it

I'm not going to completely dismiss the such a practice may be plain old cargo-culting...

But as devils-advocate, properties are implemented as methods/functions, and as such (under the hood) accessed through a vtable.

This means they can be overridden in derived (generated) classes, which can then implement things like change-detection and other stuff which may be of use for a data-access/persistence class. And these derived classes can be returned in place, without the calling code knowing nothing about it.

> They make explicit reference to an objects internal fields

Not really. A property is supposed to be a public API, and definitely not "internal".

Re: Data Classes for Java

#185

Post by sailorman » Thu, Nov 02, 2017, 1:38 PM UTC

Why don't you just use plain fields, and if you need to change it later, delete the field and go fix all compile errors?

Re: Data Classes for Java

#186

Post by [deleted] » Thu, Nov 02, 2017, 1:55 PM UTC

derefr wrote: post #10

HumanDrivenDev wrote: post #2

... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…

> obfuscating what happens when you actually access them This is the point, AFAICT. In languages with both primitive "read/write field" operations that can't be interceded upon, but also with interfaces/protocols, "obfuscating" (encapsulating) a field access in getter/setter methods is how you allow for alternative implementations of the interface/protocol. Specifying your object's interface in terms of getters/sette…

[deleted]

Re: Data Classes for Java

#187

Post by ben-schaaf » Thu, Nov 02, 2017, 2:05 PM UTC

deepsun wrote: post #154

ben-schaaf wrote: post #144

Earlier quoted context omitted.

Have you actually used kotlin before? It most certainly has features that are much more than just syntactic sugar.

Yes, I use it every day and absolutely love it. Especially the part that it's still syntactic sugar over Java.

It does a lot more than just syntactic sugar. It expands the type system with nullable types, smart casts and covariant/contravariant generics, and it has actual closures. I agree that most of the features kotlin provides are syntactic sugar over Java, but kotlin is as much a separate language to Java as Scala is.

Re: Data Classes for Java

#188

Post by atoko » Thu, Nov 02, 2017, 2:33 PM UTC

hackits wrote: post #128

HumanDrivenDev wrote: post #122

Earlier quoted context omitted.

What do you mean by "real objects"? Are you refering to prototype OO?

Yes similar to a prototype language. The original design goals of OOP was you removed your constraints from the machine language and the restrictions that comes with a state based machine. Instead of focusing on mutex’s, member fields, private/public functions inheritance. You took your problem domain and deconstructed it using basic-level categorization into objects. Those objects themselves would have behaviors and…

"{}.f is not a function"

oh..

Re: Data Classes for Java

#189

Post by wvenable » Thu, Nov 02, 2017, 2:35 PM UTC

usrusr wrote: post #155

wvenable wrote: post #132

Earlier quoted context omitted.

If you get married, you might "changeLastName" or maybe even "rename" yourself but if you're just moving that name from one place to another you'd "set" it. You could probably come up with lots of different names but none of them will be more clear than "set" in this case.

If moving requires a name to be set you are at constructor time, no need for permanently available setters.

Two things with that, you're assuming immutability but even a simple database entity object wouldn't be immutable. And secondly, anything over a handful of values and setting them via a constructor isn't pretty.

Re: Data Classes for Java

#190

Post by kbp » Thu, Nov 02, 2017, 3:23 PM UTC

derefr wrote: post #10

HumanDrivenDev wrote: post #2

... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…

> obfuscating what happens when you actually access them This is the point, AFAICT. In languages with both primitive "read/write field" operations that can't be interceded upon, but also with interfaces/protocols, "obfuscating" (encapsulating) a field access in getter/setter methods is how you allow for alternative implementations of the interface/protocol. Specifying your object's interface in terms of getters/sette…

> But in a language like Java, where field access has its own semantics divorced from function calls, you need getters/setters to achieve a similar effect.

I think the problem with Java's approach wasn't just in allowing primitive slot access, it was in making that access be simpler and use less boilerplate than accessor access, so people are tempted to use it where it isn't really what they specifically want, and accessors feel like extra work. I think that most of the time when people complain about getters and setters, their main issue is just the extra syntax they require in languages like Java.

In contrast, Lisp makes using accessors the path of least resistance, so if someone does use primitive slot access, they probably consciously really wanted that. In a class definition like:

    (defclass my-class ()
      ((x :accessor x)))

The :ACCESSSOR option lets you write (x instance) and (setf (x instance) new-value); with or without it you can write (slot-value instance 'x) and (setf (slot-value instance 'x) new-value) for primitive slot access. It's really just a shorthand for defining methods like:

    (defmethod x ((my-class my-class))
      (slot-value my-class 'x))

    (defmethod (setf x) (new-value (my-class my-class))
      (setf (slot-value my-class 'x) new-value))

But just by providing that little shortcut (and by not having a shortercut for primitive access) it's enough to make getters and setters the default in a way that people rarely complain about.