Properties

[ІП-24 Олександр Ротань]

>  First, I don’t agree that properties have become an industry standard.
Not all languages, even those newer than Java have them. ....  The two
languages with similar or higher popularity to Java’s have fewer features
than Java, not more.

I have to agree with the point that JS, and Python (as I reckon that's the
ones you are referring to) have less features then Java. However, what I
would like to say is that, in my opinion, they are popular despite, not due
to it. Less features and simple syntax obviously make them easier for
learners, but that mostly comes from their interpreted nature, which comes
at the cost of dramatical performance differences. Still, what the market
currently indicates (I am not an analyst of any kind, this is just my
observations), is that most popular languages, especially for product
companies, are the ones that help *write* code faster at cost of support
terms. I agree with Java prioritizing second over first, but language
paradigms, as for me, should shift along with the market at least to some
extent. So to conclude, while most popular languages *do* have fewer
features, they still provide better developer experience due to their
interpreted nature, and their popularity is caused by better developer
experience, not by the amount of features in them.

> While setters remain inevitable, if the need for them drops, the problem
of writing them more easily becomes smaller, and a smaller problem doesn’t
justify a language feature as much as a bigger problem. It makes the cost
in complexity of the feature higher with respect to its benefit.

While it makes setters a lesser problem, does it make it that small for
pros to not outweigh cons? In modern applications, 99% of the time
concurrency is handled by controller pattern, while the
processing environment is single-threaded, and all possible problems are
covered by things like entity managers. Data mutations are non-concurrent
in the majority of situations, if we exclude race conditions at the
database level.

> I don’t agree that properties have become an industry standard.

I did some research on that. Let's consider only backend languages here so
we judge popularity across similar languages: I will use PYPL rankings as
it gives, as I think, the most accurate top 15. (Let's not refer to TIOBE
here for obvious reasons)

Out of 15 most popular programming languages, there are 6 languages that
are mostly used in backend: Python, Java, JS/TS, C#, Go and Kotlin.
Languages that have properties: TS, C#, Kotlin.
Languages that don't: Python, Go (and Java).

Each of the languages that doesn't have properties has its reason to it:
python essentially doesn't have any encapsulation, Go just dont have
classes, only structs (same for Rust by the way). All languages that were
designed for OOP and server side (which essentially implies a simple domain
model), have properties. There aren't many languages to have comprehensive
statistics, but even now (especially if we weigh these languages with their
popularity), properties are much more popular then no properties. Also
judging by popularity now isn't the best way of doing measurements: best
languages now will be most popular in a decade at least. For example, I
have done more deep research for my country (Ukraine). With the start of
war, the market significantly shifted towards product companies from
outsource, and now, when it comes to building apps from scratch, C# is the
most popular choice. Concluding, while I might have really put too much
into saying it is an industry standard, this is clearly a popular choice.

Also, what I always point out is that developer experience is tightly
linked to measurements like TTM and errors per line of code in languages,
and while dropping into users demand completely like python or js do is
obviously not the best choice, In my opinion, optimal point is somewhere
closer to where C# currently is, not where Java is. (Although some features
of C# like arrays pattern matching are obviously redundant, so not that
close to C# :) )

Appreciate Andrew`s comment, I haven't looked at it from this perspective,
but when it comes to syntaxic sugar and not root features, I think that is
not really applicable as it is transformed to recognizable for JIT syntax
during compilation.

PS: I think I am not in a position to say what is right and wrong in
approach of many experienced developers that guide Java`s development, but
I think that when you are coming into discussion with mindset of trying to
find the reasoning why not to introduce something, it might be harder to
actually evaluate all pros and cons. As I understand, even if pros outweigh
cons, but not significantly enough, features are discarded. As for me,
that`s not the best way to go with requests that are popular in the
community.

PPS: I would appreciate any feedback on this. And also about init-only
fields, is there some thoughts regarding them in the community? I feel like
it aligns pretty well with where jdk developers are heading currently

ср, 24 апр. 2024 г. в 16:25, ІП-24 Олександр Ротань <
rotan.olexandr at gmail.com>:

> No, I am sorry, I had to write the last message from my phone and didn't
> notice the error. Thanks for letting me know
>
> ср, 24 апр. 2024 г. в 16:11, - <liangchenblue at gmail.com>:
>
>> Is this intended to go to the mailing list or just to me?
>>
>> On Wed, Apr 24, 2024 at 8:04 AM ІП-24 Олександр Ротань <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Also, what I always point out is that developer experience is tightly
>>> linked to measurements like TTM and errors per line of code in languages,
>>> and while dropping into users demand completely like python or js do is
>>> obviously not the best choice, In my opinion, optimal point is somewhere
>>> closer to where C# currently is, not where Java is
>>>
>>> On Wed, Apr 24, 2024, 15:54 ІП-24 Олександр Ротань <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> Well as a compromise between mutable and immutable objects there could
>>>> be init only fields. What is regarding to property mutations being
>>>> antipattern, it may have as many downsides as possible, but still is
>>>> inevitable in production, and, moreover, is one of the most popular tasks
>>>> to perform. Entities are mutable by specification, and there is nothing we
>>>> can really do about that.
>>>>
>>>> I also appreciate Ron Pressler's clarifications, this makes everything
>>>> a lot more understandible for me.
>>>>
>>>> What I would like to say on this topic is that while immutability is
>>>> understandible trend nowadays, when we are talking about production, the
>>>> major part of the work is working with entities, which are inheritandably
>>>> mutable (and in many cases at least some of their properties should remain
>>>> that way).
>>>>
>>>> Current workarounds that exist to avoid undesired mutations is to
>>>> expose public constructor with required fields while making no-args
>>>> constructor protected, along with ommiting setters for such fields.
>>>>
>>>> Init only fields would probably be fix to problems of mutability, I may
>>>> also do some research on them, but what I would like to say is that some
>>>> properties are just mutable by their nature (like email fields, or amount
>>>> of attempts left), and this is still a very widely encountered case and
>>>> will surely remain so.
>>>>
>>>> Also, that's all discussion about set accessors. What about get
>>>> accessors, I don't really see downsides of them, and it would be a neat
>>>> addition that could freshen up a language
>>>>
>>>> Edit: Ron, I saw your last message just now, so I will reply to some of
>>>> the points here.
>>>>
>>>> Firstly, I have already addressed that setters are effectively
>>>> inevitable, init only fields could do the trick you are trying to do by
>>>> disencouraging setters (which is a great by the way, I also think that even
>>>> for mutable objects immutability should be preserved where possible).
>>>>
>>>> About language complication, I get this point, concise syntax of Java
>>>> is why I fell in love with it in the first place. But as the time moves, it
>>>> becomes clear that some features just become industry standard: properties,
>>>> previously discarded extensions, object deconstruction etc. While I agree
>>>> that language should not just blindly accept every possible feature, wide
>>>> usage of some may indicate (and indicates) there is a demand for those. I
>>>> understand the desire to make language better by omitting the road that
>>>> once tricked languages like c++, but I think sometimes, when demand is high
>>>> enough, we should let users have what they want. At the end of the day,
>>>> trere isn't a problem in more flexible approaches, but some of the most
>>>> common problems, in my opinion, should be addressed specifically. This way
>>>> we could have a perfect balance between user experience and code quality.
>>>>
>>>> On Wed, Apr 24, 2024, 15:30 - <liangchenblue at gmail.com> wrote:
>>>>
>>>>> No, field modification is an antipattern and should be avoided at
>>>>> best, so both of the direct setfield instruction or a setter call are
>>>>> antipatterns, as these can be made from other threads and cause
>>>>> unpredictable memory effects. For entity mutations, it's recommended that
>>>>> they are only accessed single threaded to avoid incorrect programs.
>>>>> However, you probably still don't want setters, as this implies the fields
>>>>> are not related to each other and all cartesian products of all fields are
>>>>> possible, which is rarely the case and such usages are still better covered
>>>>> by records.
>>>>>
>>>>> Regards
>>>>>
>>>>> On Wed, Apr 24, 2024 at 7:22 AM ІП-24 Олександр Ротань <
>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>
>>>>>> I am not fully getting it. So things like foo.prop = val is
>>>>>> antipattern while foo.setProp(val) is not? What about objects like
>>>>>> entities, where constant data mutations are inevitable and classes are
>>>>>> mutable by spec?
>>>>>>
>>>>>> On Wed, Apr 24, 2024, 15:18 - <liangchenblue at gmail.com> wrote:
>>>>>>
>>>>>>> Hi Oleksandr,
>>>>>>> Such properties are an antipattern in Java nowadays. We should
>>>>>>> prefer immutable objects and records/builders instead. Mutations should
>>>>>>> happen on the stack as much as possible for thread safety. And record
>>>>>>> components already accomplish the "property" feature in an immutable sense.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> On Wed, Apr 24, 2024 at 4:24 AM ІП-24 Олександр Ротань <
>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>
>>>>>>>> As I see extension methods haven't been accepted as gladly as
>>>>>>>> expected, I decided to put them in stash for now and work on some other
>>>>>>>> features that I think Java lacks for now.
>>>>>>>>
>>>>>>>> I think properties (seamless access to them to be precise) would be
>>>>>>>> a great addition, but having my previous experience, I want to ask were
>>>>>>>> there any discussions about that previously.
>>>>>>>>
>>>>>>>> Also, if there wasn't, or at least properties were not rejected, I
>>>>>>>> have a few questions regarding implementation that I want to know community
>>>>>>>> opinion about.
>>>>>>>> Firstly, I think, having all the codebase populated with get and
>>>>>>>> set accessors, the best way to add such thing would be to treat getX as a
>>>>>>>> get accessor to property X and setX correspondingly.
>>>>>>>> Secondly, unlike C# for example, I think that absence of property
>>>>>>>> accessor should just imply direct access instead of forbidding it (in C#,
>>>>>>>> int a {get;} implies a is effectively immutable)
>>>>>>>> Lastly, for the sake of backward compatibility, I guess if a
>>>>>>>> variable is directly visible in scope, I think that it should be modified
>>>>>>>> directly rather than through an assessor. While that severely damages data
>>>>>>>> integrity, this will not introduce any source code incompatibilities
>>>>>>>> (bytecode incompatibilities isn't a thing here if properties will
>>>>>>>> be desugared in compile-time)
>>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/4c2d7f29/attachment-0001.htm>