
<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

</head>

<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">

<p dir="auto">FWIW I agree with Danâ€™s point.</p>

<p dir="auto">The Carrier API should throw IAE if Object does <em>not</em> appear in all the MethodType places where the eventual (mysterious encapsulated) carrier object will appear.</p>

<p dir="auto">If tomorrow we figure out a clever use for client-specified types there (such as Record or List), then mandating Object today will give us flexibility to extend tomorrow.</p>

<p dir="auto">Also, I donâ€™t see any plausible use cases for a client-specified carrier-placeholder type other than Object.</p>

<p dir="auto">Also, mandating Object will make it slightly easier to deal with the problem of static prediction (for static-image applications that Dan referred to), since thereâ€™s one less degree of dynamic freedom.</p>

<p dir="auto">On 9 Mar 2022, at 7:03, Dan Heidinga wrote:</p>

</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">On Wed, Mar 9, 2022 at 9:26 AM Brian Goetz <brian.goetz@oracle.com> wrote:</p>

<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #BBBBBB; color: #BBBBBB;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #BBBBBB; color: #BBBBBB;"><p dir="auto">The minimal constraint is that the return type of the constructor MH is the same type as the argument type of the component MHs.</p>

</blockquote><p dir="auto">Agreed.  The types should match but they shouldn't be considered part

<br>

of the api.  I don't think (correct me if I'm wrong) that we want them

<br>

to "escape" and be baked into classfiles.  The implementation of the

<br>

anonymous class holding the fields ("holder object") should remain as

<br>

a hidden implementation detail.  One way to do that is to enforce that

<br>

the holder object is always hidden behind other public types like

<br>

Object.</p>

</blockquote><p dir="auto">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?</p>

</blockquote><p dir="auto">Having the Carrier api do the laundry ensures that the implementation

<br>

details don't leak into MH/MT constantpool entries.  And encourages

<br>

users not to try to be overly clever and rely on the implementation

<br>

details.  The more they do that the harder it will be to evolve the

<br>

implementation in the future.</p>

<p dir="auto">The Q-ness should just flow through the APIs - I don't see an extra

<br>

cost here.  Either it's all used in the same JIT compilation unit and

<br>

there's full type visibility or its not and the Q may have to hit the

<br>

heap to flow along the callstack.  The costs are the same whether the

<br>

descriptors say Q or not.</p>

<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #BBBBBB; color: #BBBBBB;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #BBBBBB; color: #BBBBBB;"><p dir="auto">It would seem to me that preserving stronger types here dynamically gives MH combinators more room to optimize?</p>

</blockquote><p dir="auto">Only the outer edge of the MH chain would need to return (constructor)

<br>

/ take (component) Object.  The implementation of the MHs can use a

<br>

sharper type.  I don't think we gain any optimization abilities here

<br>

by exposing the sharper type - at worst there's an asType operation to

<br>

check the type but that shouldn't be visible in the performance

<br>

profile.</p>

</blockquote><p dir="auto">OK, so youâ€™re saying itâ€™s fine to slap an Object label on it, as it will come off easily when needed.</p>

</blockquote><br></blockquote></div>

<div class="markdown" style="white-space: normal;">

<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">

<p dir="auto">That's my assertion.</p>

</blockquote>


</div></div></body>


</html>