On 09/26/2018 09:44 AM, Andrew Dinn wrote: > As regards the latter issue, I am not really sure what you are > suggesting would be a better alternative to using ByteBuffer get and put > methods? Are you perhaps thinking of some way of overlaying a record (or > object?) structure over the mapped memory that might allow a compiler to > provide an equivalent to these ByteBuffer method calls as direct memory > loads and stores? Of course, a Java library built on top of this > proposal could provide a similar abstraction, although perhaps not with > as firm guarantees for compiler optimization and certainly not with the > possibility of direct language integration.
Thinking about it some more, I guess that being able to say something like aFoo.bar = n; rather than aFoo.setBar(n); is preferable, although common Java practice (and indeed good OOP practice) is to provide getters and setters rather than directly expose fields. I suppose one advantage of being able to use an object structure is that the compiler can do better (type-based) alias analysis, can track dead stores, etc. But from a language design perspective, the fact that classes internally use direct field accesses but expose a completely different get/set notation is something of a linguistic wart. [ The BETA language used a single notation, the pattern, for assignment, method calls, and argument passing. Therefore, in BETA there would be no API difference between the two exaples above. They'd both be something like n -> aFoo.bar Curiously, the first commercial licences for BETA were acquired by Bill Joy and James Gosling, so they knew about this, but I suppose a more C-like notation for Java was the right decision. The BETA notation would have been too frightening for the target audience. :-) ] -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
