Inline Record

[John Rose]

Yes, you are elaborating on one of the directions I’m poking at, which
is reflective customizability.  The other direction is finding new places
to “hook it in”, which Remi referred to.  Brian’s terse response that
“value types are already covered” is the weak place of my half-baked
proposal, and (frankly) the reason it cannot be fully baked.  But the
other parts point in the directions you and Remi have engaged.

> On May 7, 2020, at 5:33 AM, Kasper Nielsen <kasperni at gmail.com> wrote:
> 
> 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