[
https://issues.apache.org/jira/browse/LUCY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256908#comment-13256908
]
Marvin Humphrey commented on LUCY-232:
--------------------------------------
As discussed on IRC...
The issue which the first patch deals with has been resolved by r1327658: "Use
default parcel for method parameter variables".
The second patch takes a good approach, but should be tweaked to look for the
first capital letter rather than an underscore. This is because...
* The short struct name for an object type *must* begin with a capital
* CFCParcel_prefix() may contain multiple underscores, but cannot contain a
capital.
> 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
