[
https://issues.apache.org/jira/browse/LUCY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Wellnhofer resolved LUCY-232.
----------------------------------
Resolution: Fixed
I consider this issue fixed with Marvin's commit in r1327728. In the long run,
it should be possible to use types from other parcels without specying a prefix
at all. But that's outside the scope of this ticket.
> 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
