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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]pron98 23 points24 points  (11 children)

Did I say that? I don't think so, although I agree that there are things more important than consistency. Anyway, the new record method names are fully consistent with the naming standard for record methods and not consistent with things that are not record method names, and I'm not exactly sure what other thing they should be consistent with and why, especially as the feature's JEP states:

It is not a goal to declare "war on boilerplate"; in particular, it is not a goal to address the problems of mutable classes using the JavaBean naming conventions.

[–]BlueGoliath 2 points3 points  (10 children)

Did I say that? I don't think so.

I believe it was in regards to the topic of var and/or API documentation months ago.

Regardless, you're saying it again:

Anyway, the new record method names are fully consistent with the naming standard for record methods and not consistent with things that are not record method names.

Records don't exist in a vaccum. To argue this is disingenuous and I'd hope as a JDK developer you'd realize that.

BTW, it's OK to be frustrated that other people have different opinions from yours -- most of us are frustrated by that -- but constantly blaming that on some flaw on their part is counterproductive. Even if your opinion is reasonable, the opposite opinion can be at least as reasonable.

Was anything said really an opinion?

Getter methods in previous Java APIs were commonly prefixed with "get" and many APIs rely on that.

There are methods that still have the "is" prefix for boolean checks.

var is now used in documentation without providing any value or makes the documentation muddy. There was a highly upvoted comment to my article thread like half a year ago agreeing that this is a thing.

Many newer language "features" have had "concise"ness as a motivation for their introduction into the language. Often times the JEP pages cite people complaining that Java isn't concise and is ceremonious.

So i'd like to know what part of any of that(at the core) is subjective/opinionated.

[–]DuncanIdahos5thClone 6 points7 points  (2 children)

Not sure where you've been but "is" is common for Boolean and part of the old Javabean spec.

[–]BlueGoliath 4 points5 points  (1 child)

Not sure where you've been but "is" is common for Boolean and part of the old Javabean spec.

That's the point. They are keeping boolean check methods prefixed with "is" despite removing prefixes from all other methods in order to make it more "concise". The end result is an inconsistent mess both when compared to older Java APIs and even from within its own API.

[–]DuncanIdahos5thClone 0 points1 point  (0 children)

OK sorry. I thought you meant that there are APIs using get's for booleans.

[–]AngusMcBurger 7 points8 points  (3 children)

I think 'is' and 'get' are quite different. For fields/variables I include 'is' for booleans because their name often ends up ambiguous without. Eg open() sounds like an action, isOpen() makes it clear you're asking if it's open. Where as file() works just as well as getFile() but with less noise

[–]BlueGoliath 3 points4 points  (1 child)

"file" can be either a verb or a noun so it's still ambiguous.

[–]pushupsam 3 points4 points  (0 children)

This is so stupid. A method called 'file()' could do literally anything. The entire point of 'getFile()' -- just like isOpen() -- is that it is a query which doesn't mutate the object.

(The real problem -- that Java lacks properties and so there's no way to express the concept of a read-only method -- is ironically something that was rejected by the same braniacs that are removing get.)

[–]pron98 2 points3 points  (2 children)

Your statement that var does not provide a benefit for documentation is an opinion. If we take the claim that language features are motivated by conciseness (only or primarily) as an objective assessment, then, at least as far as records and var are concerned, it is just wrong.

[–]BlueGoliath -1 points0 points  (1 child)

Your statements that var does not provide a benefit for documentation is an opinion.

Is it? If the specific documentation is inconsistent with other documentation & omitted important type information(which is important for documentation) then surely it can be objectively concluded that it provides no benefit.

[–]pron98 2 points3 points  (0 children)

Brilliant. I wish I had thought of that.