On Wed, Jun 24, 2015 at 4:14 AM, Nick Wellnhofer <[email protected]> wrote:
> On 24/06/2015 04:18, Marvin Humphrey wrote:
> With interfaces, we have the problem that there
> are two types from possibly different parcels involved. So some of the
> symbol names will need two parcel prefixes. With the "short names" feature,
> we can only avoid one of them.
I'm hoping that it will generally be the compiler that has to deal with those
names.
>> Interesting that host_obj ostensibly stores a void*, but you're passing it
>> an integer array tick.
>
> That's because we currently use `void*` for host objects. In Perl, it would
> be an `SV*`, for example.
>
> I thought about adding a typedef for the host object type to
> `cfish_hostdefs.h`. But for Perl, this would either require to include some
> Perl headers, or a forward declaration of `SV`.
It's fine but should be commented.
> Consider a method with an interface type argument
>
> Obj*
> Fetch(Hash *hash, Hashable *key);
That should be `Hashable key` rather than `Hashable *key` -- right?
>
> that is called from the host language:
>
> // Go
> val = hash.fetch(key)
>
> # Perl
> $val = $hash->fetch($key);
>
> `key` could be either a Clownfish or a host language object implementing
> Hashable. In the case of a Clownfish object, we need some way to lookup the
> correct itable and create an interface object. For Go, I solved this with
> the `UNWRAP*` methods which seems like the most efficient solution.
Does this approach make sense?
https://github.com/rectang/lucy-clownfish/commits/iface_exp1
Obviously some of that code would be autogenerated by CFC.
I think it would work for Perl, Python, Ruby, etc -- languages which
resolve method names on each invocation.
Notes:
* Generate one Host{$INTERFACE} class per interface.
* Call the methods via standard host name-based dispatch.
* Allocate the wrapper object on the stack, similar to our approach with
stack-allocated String.
Marvin Humphrey
