Constructor Makeover in Java 22

[mfiguiere]

https://blog.jetbrains.com/idea/2024/02/constructor-makeover-in-java-22/

[charcircuit]

People shoving logic into the arguments of super made this restriction pointless. I'm glad they are removing it.

[keeganpoppen]

who are all these people cramming validation into all their crap everywhere? like, i don’t know if im in the wrong line if work or what, but somehow i seem to wind up with a constructive approach to 99% of problems in “validation land”… it just seems so fake to me. maybe like the declarative versions where you can just say aspirationally that you know by fiat that values are within some bounds… that i think i grok…

it’s not like i don’t throw landmines into the holes where my error cases lie, it’s just so far from my dominant experience in programming. like, “validating”, per se, literally does nothing on its own to get you to a solution. it only exists to tie your hands to your knees so they dont wind up around your back. and that feels kind of charitablec since hands-behind-back is actually fairly useful (at least, it is for fairly broad-shouldered types like yours truly).

[iraqmtpizza → keeganpoppen]

I wouldn't call this validation (except at the very end). I would call it parsing. In fact it serves the purpose of not having to duplicate the validation code which is centralized in the canonical constructor.

    public Function(String signature) {
        this(signature, signature.indexOf('('), TupleType.EMPTY);
    }

    public Function(String signature, String outputs) {
        this(signature, signature.indexOf('('), outputs != null ? TupleType.parse(outputs) : TupleType.EMPTY);
    }

    private Function(final String signature, final int nameLength, final TupleType<?> outputs) {
        this(
                TypeEnum.FUNCTION,
                signature.substring(0, nameLength),
                TupleType.parse(signature.substring(nameLength)),
                outputs,
                null,
                Function.newMessageDigest()
        );
    }

    public Function(TypeEnum type, String name, TupleType<?> inputs, TupleType<?> outputs, String stateMutability, MessageDigest messageDigest) {
        this.type = Objects.requireNonNull(type);
        this.name = name != null ? validateName(name) : null;
        this.inputTypes = Objects.requireNonNull(inputs);
        this.outputTypes = Objects.requireNonNull(outputs);
        this.stateMutability = stateMutability;
        this.hashAlgorithm = Objects.requireNonNull(messageDigest.getAlgorithm());
        validateFunction();
        generateSelector(messageDigest);
    }

[keeganpoppen → keeganpoppen]

i guess one could take the tack of my argument being strained in the sense that it is as much contra type systems as it is contra “validation”. which is fair and mostly true. but, i mean… have you ever tried to actually use some of these type systems, man? the other day i had to find a way to completely fuck my whole project’s structure just so that i could get a stupid dataclass union type field to bind at an appropriately late time. self-immolation would be far preferable…

[TrianguloY]

Isn't it easier to create a static constructor? A public static method that validates everything, then calls the private constructor with the proper values?

Using a static private method that is "hacked" as a call to the super constructor in the public one seems...strange.

[tadfisher → TrianguloY]

It's better to not confuse data with behavior. Move the polymorphism to the data type, and model the behavior with an interface. Now you don't have to validate arguments to super() because there isn't one.

[iraqmtpizza → tadfisher]

You can't have default methods for equals, hashCode, and toString in Java interfaces. And even if you could, without access to the data they wouldn't be of much use.

[keeganpoppen → TrianguloY]

i find static constructors somehwat hideous in the sense that ultimately inevitably ends up running through the constructor regardless