Inline Record

[Kasper Nielsen]

On Thu, 7 May 2020 at 00:16, John Rose <john.r.rose at oracle.com> wrote:
>
> Crazy half-baked idea of the moment:
>
> Factor the equals/hashCode/toString methods for records into
> static methods (in ju.Objects) which are configurable appropriately,
> and have a default configuration.  Use ClassValue for performance.

Shouldn't these methods live in jl.invoke instead of ju.Objects?

Isn't the real kicker that you can easily generate customizable MHs?

Such as:
(receiverType)String
MethodHandle recordStringGen(Class<? extends Record> receiverType, CharSequence
delimiter, CharSequence prefix, CharSequence suffix)

Or even generalize these methods for "entities with nominal component parts":

(receiverType)String
MethodHandle stringGen(Class<?> receiverType, Map<String, MethodHandle>
componentExtractors, CharSequence delimiter, CharSequence prefix, CharSequence
suffix)
Where each MH in componentExtractors takes a receiverType and returns a
toString()'able object. And the key is the component name.

This could be useful for people working with JavaBeans, JPA entities, ect.
(might be some issues with the module system and readability from a base class).
But kind of a pull-based version of StringConcatFactory::makeConcat.

Also, would it make sense to create an actual subclass MHCV of CV for this
(while still supporting constant-folding ClassValue::get)? You could then
restrict all non-receiver types in the constructor MHCV(Class<?>...
parameterTypes). I would think you would always want all arguments to be of the
same type except for the receiver? I assume this would mean you could avoid
some runtime checks for invokeExact on whatever MHCV::get would return.
If you always know the exact shape of it?

> Then define equals/hashCode/toString in jl.Object (yes, Object)
> to call those methods, *when the receiver is a Record and/or an inline*.

For Record, what benefits would you get for putting the logic into
Object instead of the Record class/interface?

Thanks,
  Kasper