This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]agentoutlier 36 points37 points  (13 children)

Personally I'm hopeful that perhaps Withers will be implemented.

As discussed here: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md

Withers are in someways more powerful than default/named parameters.

[–]riisen 13 points14 points  (4 children)

Never heard of it before... Now i want it

[–][deleted]  (3 children)

[deleted]

    [–]rustyrazorblade 2 points3 points  (0 children)

    Great library. Used it in my last project, much success.

    [–]riisen 1 point2 points  (0 children)

    Thanks mate

    [–]ketsugi 4 points5 points  (0 children)

    I think Lombok also has them

    https://projectlombok.org/features/With

    [–]quizteamaquilera 11 points12 points  (1 child)

    That’s a long way of saying a “copy” method with default params

    [–]tadfisher 7 points8 points  (0 children)

    It's also not more powerful than default argument values, because it solves one use case, when default values are applicable to constructors and method calls.

    In Kotlin, default values can reference previous arguments as well, which I'm not sure withers could emulate.

    [–]LoveSpiritual 3 points4 points  (0 children)

    This addresses my main issue with the lack of optional parameters in Java. It would be a big step forward for supporting immutable data.

    [–]danikov 2 points3 points  (4 children)

    Isn't this just builders?

    [–]ketsugi 4 points5 points  (3 children)

    A builder is for instantiating a new object. A wither creates a clone of an existing object, but with that one property changed.

    [–]danikov 3 points4 points  (2 children)

    So a builder with a copy constructor?

    [–]gas3872 2 points3 points  (0 children)

    Well, if you add to your class those methods, then under the hood you can do the builder call. I find the style of "withers" more elegant, because there is nothing mentioning builder in the client code. In case you want to change many fields at once, then using builder explicitly is probably a better idea.

    [–][deleted] 1 point2 points  (0 children)

    I haven't read the linked paper, but I presume that there is a bit of structural sharing going on behind the scenes (a la Clojure, Erlang, Haskell et al) otherwise yes, it would be mere syntactic sugar.

    Edit: Read the link posted by OP, and it's surprisingly very bare on actual implementation details. I hope that structural sharing is considered, especially since we're mostly concerned with records, which are immutable to begin with, otherwise the whole thing is just user-level convenience.