On 17.09.2012 11:48, Igor Stasenko wrote:
On 17 September 2012 11:19, Henrik Sperre Johansen
<[email protected]> wrote:
On 16.09.2012 20:42, Stéphane Ducasse wrote:
On Sep 16, 2012, at 7:17 PM, Igor Stasenko wrote:

So, i'd like to hear your input, which one you like, and which ones
you prefer to have

1. requires creating a subclass of NBFFICallback, overriding it's
fnSpec method. Takes a block closure as a callback.
2. first you must create a factory object by specifying a callback
signature, then you can instantiate new callbacks by passing a block
closure to that factory
3. to create a callback you must specify it's signature in one of the
compiled methods, and specify an object which will receive a message
when callback will be called.
for what it is worth I like the 3rd form. Now I'm not sure on: is the
right selector.

+1, out of those listed #3 seems the most convenient to use.

Being able to do something like:
Integer >> #+
<types: #( int (int aNumber) )>

Then specify the callback parameter as
self callback: 3 with: #+

would be really neat.

As an added bonus, it also highlights the problems this approach would have
with simply annotating normal methods which utilize multiple
return/parameter types :)

not sure i understood your sentence about problems.

Integer + can return LargePositiveIntegers as well as SmallIntegers.
Argument type can be anything from float, to Fraction, to.. well, any kind of number.

So annotating such methods with a single <types> annotation (which is to serve all uses of it as a callback), rather than defining signature on a per-use basis can be somewhat limiting and end up working against the inherent polymorphism you (at least when it comes to numerics) see in usual smalltalk code.

When it comes to return values that's mostly fine, you simply raise an error if unable to convert to the specified type from what the smalltalk method actually returns.

But for parameters, you'd have to define separate methods per signature, say
addFloat: <types: #( int (float aNumber) )>
addUnsignedInt: <types: #( int (uint aNumber) )>

when #+ actually handles those cases correctly.

Maybe a way to "override" the default parameter signatures when specifying the callback would be nice?
self callback: 3 with: #+ parameterTypes: {aNumber -> float}

Leaves the usefulness of a default signature for a method, but enables you to change it on a per-use basis, rather than pollute the base-image with extra methods covering parametric variances.

Cheers,
Henry

Reply via email to