<div><div dir="auto">Hi Marcel:</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 19 Jun 2020 at 1:15 pm, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"> <div id="m_4219620875839454893__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">Hi all!<div style="font-family:Arial"></div><div style="font-family:Arial"><br></div><div style="font-family:Arial">We have #doesNotUnderstand:, which is sent to the receiver when a message cannot be understood. Default reaction in Object is to raise MessageNotUnderstood exception.</div><div style="font-family:Arial"><br></div><div style="font-family:Arial">What if we could have a similar mechanism for FFI calls: #doesNotCoerce:for:. The receiver would be the one that made that call, should be an instance of ExternalLibrary, but could be any object. The arguments would be a pair of (argObject, argType) and the message (like the argument for doesNotUnderstand:) that represents the FFI call.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">I don't like the idea of adding a plugin-specific mechanism like this to the VM. I know it's not as convenient, but maybe something similar can be achieved with error codes in fallback code? There already is BAD_ARGUMENT, maybe there's a way to encode which argument is bad in the error code?</div><div dir="auto"><br></div><div dir="auto">Fabio</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div id="m_4219620875839454893__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)"><div style="font-family:Arial"></div><div style="font-family:Arial"><br></div><div style="font-family:Arial">The pair of (argObject, argType) could be expressed as FFICallArgument:</div><div style="font-family:Arial"><br></div><div style="font-family:Arial">FFICallArgument</div><div style="font-family:Arial">   argObject  ... <Object></div><div style="font-family:Arial">   argType ... <ExternalType></div><div style="font-family:Arial"><br></div><div style="font-family:Arial">I suppose that such a new class would have to be reserved in the special objects array. An alternative would be to just use Array. Keep it simple. ;-)</div><div style="font-family:Arial"><br></div><div style="font-family:Arial">Default reaction could be to implement #doesNotCoerce:for: in Object (as *FFI-Kernel extension) to raise FFICallArgumentNotCoerced exception (to be implemented). Also, we could implement manual coercion in ExternaLibrary to, for example, wrap atomics into their aliasing structures.</div><div style="font-family:Arial"><br></div><div style="font-family:Arial">ExternalLibrary >> #doesNotCoerce: callArg for: message</div><div style="font-family:Arial">   | argObject argType argIndex wrappedArg |</div><div style="font-family:Arial">   argObject := callArg first. "or argObject accessor"</div><div style="font-family:Arial">   argType := callArg second. "or argType accessor"</div><div style="font-family:Arial">   argIndex := message arguments indexOf: argObject.</div><div style="font-family:Arial">   wrappedArg := argType referentClass fromHandle: argObject.</div><div style="font-family:Arial">   message arguments beWritableObject. "Just in case ;-)"</div><div style="font-family:Arial">   message at: argIndex put: wrappedArg.</div><div style="font-family:Arial">   ^ message sendTo: self</div><div style="font-family:Arial"><br></div><div style="font-family:Arial">Please share your thoughts. :-)</div><div style="font-family:Arial"><br></div><div style="font-family:Arial">Best,</div><div style="font-family:Arial">Marcel</div></div></blockquote></div></div>