<div dir="ltr">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.<div><br></div><div>Regards</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024 at 7:22 AM ІП-24 Олександр Ротань <<a href="mailto:rotan.olexandr@gmail.com">rotan.olexandr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024, 15:18 - <<a href="mailto:liangchenblue@gmail.com" target="_blank">liangchenblue@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Oleksandr,<div>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.</div><div><br></div><div>Regards</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024 at 4:24 AM ІП-24 Олександр Ротань <<a href="mailto:rotan.olexandr@gmail.com" rel="noreferrer" target="_blank">rotan.olexandr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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. </div><div>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.</div><div>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)</div><div>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)</div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>