Properties

[-]

Hi Oleksandr,
Also a thing of note, if you have a mutable object, getter is dangerous...
An example being:
record IntArray(int[] value) {}
Is this record correct? No, the getter accesses the value array directly,
making it mutable by users. (Similarly, the record hashCode and equals are
improper as well)
You for sure have heard of other details for getters, such as deep copies,
or return an unmodifiable wrapper for collections.
Even for less controversial operations like getting the amount left, this
operation is most likely done across threads (say UI thread and worker
thread), so your variable read wouldn't be a plain read and would be
getAcquire/getVolatile, which requires an explicit getter behavior, too.

In conclusion, getter logic isn't as simple as returning a field; it has
various other actions and as a result, isn't well modeled by a simple
property.

Regards

On Wed, Apr 24, 2024 at 7:55 AM ІП-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/16b44d63/attachment.htm>