Properties

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

Firstly, about SDM. The only alternative to it is rich domain model. The
key difference is while entities in RDM execute business logic (and
sometimes database logic) on them itself, in SDM this is done with Services
and Repositories. If you have ever seen such architecture - it is a SDM
essentially. Currently, JPA promotes such approach with POJOS and
persitencee specifications, persistence providers along with spring expose
APIs like JpaRepositories and annotations like @Service. Modern Java
frameworks are harnessed to suit SDM.

About init-only fields. They usually are a compromise between legacy specs
and immutability, but could also have other usages. They are pretty much
like readonly fields but could be set from anywhere where setter is
exposed, *only for once* (initialization i nconstructor also counts as
intiialization of field). Then they become final. When it comes to
persistence specifically, they help to make some fields of entities
effectively immutable. Also the yare hepful if field cant be set by
constructor for some reason right away, so accessor should be exposed (it
is usually a bed design, but there are some exceptions like asyncronous
tasks ran in the background that initialize field, while response arent
dependent on it and has to be sent right away). Summarizing, its main
application is in the entities, which could seem narrow, but in fact covers
a significant part of commercial developers workflow.

ср, 24 апр. 2024 г. в 17:25, - <liangchenblue at gmail.com>:

> If a bad practice is common, it doesn't mean we should go along that path.
>
> > Nevertheless, the fact nowadays is that a simple domain model
> conquered the world, and it requires accessors as it is essentially
> procedural programming.
>
> I don't know how you've reached that conclusion, but almost no Java core
> library code after Java 5 exhibits such patterns. There are getters to
> immutable properties, which are fine, but most setters are replaced by
> builders or factory methods instead. Setters are bad for JVM's JIT
> compilations too.
>
> On Wed, Apr 24, 2024 at 9:21 AM ІП-24 Олександр Ротань <
> rotan.olexandr at gmail.com> wrote:
>
>> Also what I have to say on accessors is that getters and setters of any
>> kind have been GRASP antipatterns since the first day of their existence.
>> They breach encapsulation and information expert. Nevertheless, the fact
>> nowadays is that a simple domain model conquered the world, and it requires
>> accessors as it is essentially procedural programming. Fighting accessors
>> is like fighting windmills: we could either accept and acknowledge their
>> existence and adapt to actual environment or just try to pretend like some
>> day ther will be a clear OOP in the world and in this
>> fabulous world assessors will not be used at all
>>
>> ср, 24 апр. 2024 г. в 17:13, ІП-24 Олександр Ротань <
>> rotan.olexandr at gmail.com>:
>>
>>> >  First, I don’t agree that properties have become an industry
>>> standard. Not all languages, even those newer than Java have them. ....
>>> The two languages with similar or higher popularity to Java’s have fewer
>>> features than Java, not more.
>>>
>>> I have to agree with the point that JS, and Python (as I reckon that's
>>> the ones you are referring to) have less features then Java. However, what
>>> I would like to say is that, in my opinion, they are popular despite, not
>>> due to it. Less features and simple syntax obviously make them easier for
>>> learners, but that mostly comes from their interpreted nature, which comes
>>> at the cost of dramatical performance differences. Still, what the market
>>> currently indicates (I am not an analyst of any kind, this is just my
>>> observations), is that most popular languages, especially for product
>>> companies, are the ones that help *write* code faster at cost of support
>>> terms. I agree with Java prioritizing second over first, but language
>>> paradigms, as for me, should shift along with the market at least to some
>>> extent. So to conclude, while most popular languages *do* have fewer
>>> features, they still provide better developer experience due to their
>>> interpreted nature, and their popularity is caused by better developer
>>> experience, not by the amount of features in them.
>>>
>>> > While setters remain inevitable, if the need for them drops, the
>>> problem of writing them more easily becomes smaller, and a smaller problem
>>> doesn’t justify a language feature as much as a bigger problem. It makes
>>> the cost in complexity of the feature higher with respect to its benefit.
>>>
>>> While it makes setters a lesser problem, does it make it that small for
>>> pros to not outweigh cons? In modern applications, 99% of the time
>>> concurrency is handled by controller pattern, while the
>>> processing environment is single-threaded, and all possible problems are
>>> covered by things like entity managers. Data mutations are non-concurrent
>>> in the majority of situations, if we exclude race conditions at the
>>> database level.
>>>
>>> > I don’t agree that properties have become an industry standard.
>>>
>>> I did some research on that. Let's consider only backend languages here
>>> so we judge popularity across similar languages: I will use PYPL rankings
>>> as it gives, as I think, the most accurate top 15. (Let's not refer to
>>> TIOBE here for obvious reasons)
>>>
>>> Out of 15 most popular programming languages, there are 6 languages that
>>> are mostly used in backend: Python, Java, JS/TS, C#, Go and Kotlin.
>>> Languages that have properties: TS, C#, Kotlin.
>>> Languages that don't: Python, Go (and Java).
>>>
>>> Each of the languages that doesn't have properties has its reason to it:
>>> python essentially doesn't have any encapsulation, Go just dont have
>>> classes, only structs (same for Rust by the way). All languages that were
>>> designed for OOP and server side (which essentially implies a simple domain
>>> model), have properties. There aren't many languages to have comprehensive
>>> statistics, but even now (especially if we weigh these languages with their
>>> popularity), properties are much more popular then no properties. Also
>>> judging by popularity now isn't the best way of doing measurements: best
>>> languages now will be most popular in a decade at least. For example, I
>>> have done more deep research for my country (Ukraine). With the start of
>>> war, the market significantly shifted towards product companies from
>>> outsource, and now, when it comes to building apps from scratch, C# is the
>>> most popular choice. Concluding, while I might have really put too much
>>> into saying it is an industry standard, this is clearly a popular choice.
>>>
>>> Also, what I always point out is that developer experience is tightly
>>> linked to measurements like TTM and errors per line of code in languages,
>>> and while dropping into users demand completely like python or js do is
>>> obviously not the best choice, In my opinion, optimal point is somewhere
>>> closer to where C# currently is, not where Java is. (Although some features
>>> of C# like arrays pattern matching are obviously redundant, so not that
>>> close to C# :) )
>>>
>>> Appreciate Andrew`s comment, I haven't looked at it from this
>>> perspective, but when it comes to syntaxic sugar and not root features, I
>>> think that is not really applicable as it is transformed to recognizable
>>> for JIT syntax during compilation.
>>>
>>> PS: I think I am not in a position to say what is right and wrong in
>>> approach of many experienced developers that guide Java`s development, but
>>> I think that when you are coming into discussion with mindset of trying to
>>> find the reasoning why not to introduce something, it might be harder to
>>> actually evaluate all pros and cons. As I understand, even if pros outweigh
>>> cons, but not significantly enough, features are discarded. As for me,
>>> that`s not the best way to go with requests that are popular in the
>>> community.
>>>
>>> PPS: I would appreciate any feedback on this. And also about init-only
>>> fields, is there some thoughts regarding them in the community? I feel like
>>> it aligns pretty well with where jdk developers are heading currently
>>>
>>> ср, 24 апр. 2024 г. в 16:25, ІП-24 Олександр Ротань <
>>> rotan.olexandr at gmail.com>:
>>>
>>>> No, I am sorry, I had to write the last message from my phone and
>>>> didn't notice the error. Thanks for letting me know
>>>>
>>>> ср, 24 апр. 2024 г. в 16:11, - <liangchenblue at gmail.com>:
>>>>
>>>>> Is this intended to go to the mailing list or just to me?
>>>>>
>>>>> On Wed, Apr 24, 2024 at 8:04 AM ІП-24 Олександр Ротань <
>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>
>>>>>> Also, what I always point out is that developer experience is tightly
>>>>>> linked to measurements like TTM and errors per line of code in languages,
>>>>>> and while dropping into users demand completely like python or js do is
>>>>>> obviously not the best choice, In my opinion, optimal point is somewhere
>>>>>> closer to where C# currently is, not where Java is
>>>>>>
>>>>>> On Wed, Apr 24, 2024, 15:54 ІП-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/4f6c5a2b/attachment-0001.htm>