<div dir="ltr">Hi Oleksandr,<div>Also a thing of note, if you have a mutable object, getter is dangerous... An example being:</div><div>record IntArray(int[] value) {}</div><div>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)</div><div>You for sure have heard of other details for getters, such as deep copies, or return an unmodifiable wrapper for collections.</div><div>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.</div><div><br></div><div>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.</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 7:55 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">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.<div dir="auto"><br></div><div dir="auto">I also appreciate Ron Pressler's clarifications, this makes everything a lot more understandible for me. </div><div dir="auto"><br></div><div dir="auto">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). </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><br></div><div dir="auto">Edit: Ron, I saw your last message just now, so I will reply to some of the points here.</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024, 15:30 - <<a href="mailto:liangchenblue@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" 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">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" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer 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="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" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" 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 noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer 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>
</blockquote></div>
</blockquote></div>