[Vm-dev] FFI Plugin | Proposal: Add #doesNotCoerce:for: (like #doesNotUnderstand:)

[Nicolas Cellier]

Le lun. 22 juin 2020 à 12:47, Fabio Niephaus <lists at fniephaus.com> a écrit :

>
> On Mon, Jun 22, 2020 at 9:44 AM Marcel Taeumel <marcel.taeumel at hpi.de>
> wrote:
> >
> >
> > Hi Fabio,
> >
> > > I don't like the idea of adding a plugin-specific mechanism like this
> to the VM.
> >
> > Why is that? The implementation strategy would be very clear: like
> #doesNotUnderstand:. It's just a new entry on the special objects array.
>
> There are very few mechanisms like this (aboutToReturn,
> cannotInterpret, mustBeBoolean, ...), none of them are
> plugin-specific. I'd also prefer to keep the number of special objects
> as small as possible, the FFIPlugin already reserves quite many of
> them.
>
> >
> > > There already is BAD_ARGUMENT, maybe there's a way to encode which
> argument is bad in the error code?
> >
> > That wouldn't be any better. We could not support on-the-fly packaging
> of arguments for FFI calls by relying on just the error code. Without
> on-the-fly packaging, the FFI call could likely be unsafe (e.g. everybody
> using 'int' instead of the enum type as proposed in the library) or awkward
> to program (e.g., Alien callbacks require Smalltalk blocks to be warpped
> into Callback objects).
>
> More importantly, I don't think this type of automatic conversion
> should be part of the FFIPlugin, I'd much rather see it being built on
> top of the existing infrastructure. Why can't there be a mechanism
> that looks at the FFI call in question and converts arguments before
> executing it?
>
> Fabio
>
> Exactly, that's how UFFI works.
Easier to handle error, easier to handle automatic coercion or other
application specific hook.
While implementing HDF5, I've patched DLLCC in VW too: the key is to use
double dispatching on parameter type specification and actual argument
class, instead of large sequences of if (like we find in our plugin). This
way, I can marshall my application specific data at will.

>
> > Best,
> > Marcel
> >
> > Am 20.06.2020 22:05:29 schrieb Fabio Niephaus <lists at fniephaus.com>:
> >
> > Hi Marcel:
> >
> > On Fri, 19 Jun 2020 at 1:15 pm, Marcel Taeumel
> > wrote:
> >
> > >
> > > Hi all!
> > >
> > > We have #doesNotUnderstand:, which is sent to the receiver when a
> message
> > > cannot be understood. Default reaction in Object is to raise
> > > MessageNotUnderstood exception.
> > >
> > > 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.
> > >
> >
> > 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?
> >
> > Fabio
> >
> >
> > > The pair of (argObject, argType) could be expressed as FFICallArgument:
> > >
> > > FFICallArgument
> > > argObject ...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200622/eea0d9e3/attachment.html>