Properties

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

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/552c0ad2/attachment.htm>