[External] : Re: Proposal: java.lang.runtime.Carrier

[Brian Goetz]

>> 
>> The minimal constraint is that the return type of the constructor MH is the same type as the argument type of the component MHs.
> 
> Agreed.  The types should match but they shouldn't be considered part
> of the api.  I don't think (correct me if I'm wrong) that we want them
> to "escape" and be baked into classfiles.  The implementation of the
> anonymous class holding the fields ("holder object") should remain as
> a hidden implementation detail.  One way to do that is to enforce that
> the holder object is always hidden behind other public types like
> Object.

Yes.  So my question is, who does the laundry?  Is it the carrier API (who always says Object), or the caller who is going to take the return value of the carrier constructor and stick it in an Object?  Does it make a difference?  If I take the constructor MH, and compose it with the component MHs, will having an extraneous Object signature make it harder to expose the true type (which may be a Q type), or will that routinely and reliably come out in the wash anyway?  

>> It would seem to me that preserving stronger types here dynamically gives MH combinators more room to optimize?
> 
> Only the outer edge of the MH chain would need to return (constructor)
> / take (component) Object.  The implementation of the MHs can use a
> sharper type.  I don't think we gain any optimization abilities here
> by exposing the sharper type - at worst there's an asType operation to
> check the type but that shouldn't be visible in the performance
> profile.

OK, so you’re saying it’s fine to slap an Object label on it, as it will come off easily when needed.