Hacker News Reader

Comment by desertlounger | Hacker News Reader

Yes. And with "records" (record classes, something with the characteristics of a tuple or struct) you can get further away from getter/setter boilerplate code.

View on HN

I just wish records had an easy way to facilitate and/or associate a builder with them. Wishful thinking, out of scope for what they are. And of course, it's not hard to write a FooBuilder that's defined to help construct a Foo record.

If Java records could be told to have a private constructor, I'd be completely satisfied with them. I just don't like the ability for callers to be able to directly instantiate a record without having gone through my builder to do so. I want to completely enforce that my record is instantiated with all its invariants dealt with properly. A builder is a very nice way of doing that.

I wanted to experiment with creating a "Rust-like" option and result type for Java and so figured that I would need records and pattern matching for this and I ran into exactly what you are talking about here with records and public constructors.

My solution was to create a sealed interface that permitted the None and Some records as the only classes to implement it. Those records are not available outside the package, while the interface is exposed. Using default methods in the interface I could expose a state "create()" method which would then instantiate the appropriate None or Some record. In this way you control the exposure of the construction of the specific record implementations of your interface.

You can then either interact with the option through the methods on the interface, .isOk(), .unwrap(), etc, etc, or with the upgraded pattern matching in switches with this release you could have something like

  switch(option) {
    case option when option.isNone() -> blah
    case option when option.isSome() -> foo

}

Its not as pleasing as Rust matching directly on Some and None, but it gets you pretty close.

This is not really pattern matching, that’s just a regular old if-else.

https://news.ycombinator.com/item?id=35133670

This is absolutely possible in Java and the only less-than-ideal part is the generic type having to be specified in the None case (but a trivial method fixes that as well)

This can be used just like rust and similar languages:

  switch (option) {
    case Some(var x) -> println(x);
    case None -> // TODO
  }

Hell, you can just further pattern match inside Some, like `Some(Point(var x, var y))`

Java is built upon it's community :), look no further: https://github.com/Randgalt/record-builder, although hiding the constructor behind the builder is not something I am sure supported by that library

I also remember a discussion in the mailing list about withers: https://mail.openjdk.org/pipermail/amber-spec-experts/2020-M...

Not sure where it stands now, you can ask in the mailing list about this

> I want to completely enforce that my record is instantiated with all its invariants dealt with properly

Such validation logic can be enforced in the record's compact constructor.

Yes, agreed. But not in a clean "fluent" style. There's something nice about the fluent style that appeals to me (at least).

And I don't like having to provide one constructor for every optional (default) value, when its omitted. There's just not as nice of a style. The "telescoping" constructor pattern is just really hard to use, read and maintain.

Reply on news.ycombinator.com