[lucy-issues] [jira] [Updated] (LUCY-232) Fix specifiers of imported types

["Nick Wellnhofer (Updated) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nick Wellnhofer updated LUCY-232:
---------------------------------

    Attachment: 0002-Allow-type-specifiers-of-external-parcels.patch
                0001-Loosen-criteria-in-CFCMethod_compatible.patch

I didn't understand the issue fully. The easiest for now is to force extensions to add the parcel prefix to external type names. So MyTokenizer#Equals would be declared like this:

{noformat}
    public bool_t
    Equals(MyTokenizer *self, lucy_Obj *other);
{noformat}

Patches 01-02 contain some small fixes to make this work.
                
> Fix specifiers of imported types
> --------------------------------
>
>                 Key: LUCY-232
>                 URL: https://issues.apache.org/jira/browse/LUCY-232
>             Project: Lucy
>          Issue Type: Sub-task
>          Components: Clownfish
>            Reporter: Nick Wellnhofer
>         Attachments: 0001-Loosen-criteria-in-CFCMethod_compatible.patch, 0002-Allow-type-specifiers-of-external-parcels.patch
>
>
> Here is another problem that has to be solved to support compiled extensions. I only discovered it now because I always used "parcel Lucy;" in my test extensions. When i switched to a different parcel, I got the following error message:
> {noformat}
> Non-matching signatures for mytokenizer_MyTokenizer_equals and lucy_Obj_equals
> {noformat}
> MyTokenizer subclasses Analyzer which subclasses Obj. The declaration of the Equals method looks like this:
> {noformat}
>     public bool_t
>     Equals(MyTokenizer *self, Obj *other);
> {noformat}
> Checking the signature with the one of Obj#Equals fails in two places:
> * When comparing the type of the "other" argument, it turns out that the specifier of the argument's Obj type is "mytokenizer_Obj". This should be "lucy_Obj", but the specifier is built using the current parcel during parsing. I think the solution is to store only class names during parsing, and lookup the parcels of every object type after parsing. The signature check is only the first place where this breaks. Using the wrong specifiers would cause all kinds of other trouble later.
> * When comparing the argument names, the parcel is also taken into account. This should be easy to fix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira