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

[Fabio Niephaus]

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

>
> 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 ...