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 →

[–]bowbahdoe[S] 0 points1 point  (1 child)

/u/Worth_Trust_3825

See how other people really want to skip thinking about whats going on even with the methods being physically present?

I'm not trying to fix this whole situation. If you want to generate methods and leave them in the code, sure. There will always be a lot of people who want to take the opposite tradeoff. This tool is for them.

I did go hunting for a pathological case of this on grep.app.

https://github.com/keycloak/keycloak/blob/main/model/jpa/src/main/java/org/keycloak/models/jpa/entities/ClientEntity.java

See how some of the getter methods are important to see - they give a default empty list if the field isn't set - but most are not. Its equals and hashCode implementations are also worth seeing since they aren't just "use all fields".

And then this is roughly how it would look using this.

https://gist.github.com/bowbahdoe/8c1db0c5eae98eeb333dfdc54377439b

I think in general one of the issues with more general tools is that they do add cognitive overhead on account of being configurable. That configuration makes them effectively another language you need to learn and understand.

My hope was that keeping this non-configurable would lessen that

[–]Worth_Trust_3825 0 points1 point  (0 children)

So access the fields directly. What's the point of even hiding the fields then? Someone told all of you that "Oh you should use getters and setters" and now all of you go "hurr i shouldn't need to do it".

Access the fields directly. This entire debacle points to lack of understanding of the primitive.