Properties

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

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/6cff7188/attachment-0001.htm>