lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Wellnhofer <wellnho...@aevum.de>
Subject Re: [lucy-dev] Specifiers of imported types
Date Tue, 17 Apr 2012 15:36:17 GMT
On 17/04/2012 02:42, Marvin Humphrey wrote:
> On Mon, Apr 16, 2012 at 4:36 PM, Nick Wellnhofer (Created) (JIRA)
> <jira@apache.org>  wrote:
>> 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
>>
>>
>> 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.
>
> I think the "right" way to solve this is to add an import mechanism to the
> Clownfish header language.
>
>      // Import everything from the parcel "org::apache::lucy::Lucy".
>      use org::apache::lucy::Lucy v0.4;
>
>      // Import only the "Tokenizer" type.
>      use Tokenizer from org::apache::lucy::Lucy v0.4;
>
>      // Alias Tokenizer to "LucyTokenizer".
>      use Tokenizer from org::apache::lucy::Lucy v0.4 as LucyTokenizer;
>
> The idea here is that Clownfish must eventually support type names which are
> identical except for the parcel prefix.  However, adding such a feature is
> probably going to be pretty labor-intensive.

You're right, I didn't think about that.

> If I understand your proposed solution correctly, it would not allow the same
> type name to exist in multiple packages, so that for the time being CFC will
> effectively ignore parcels and impose a single global namespace for types.
> That state of affairs does not preclude us from adding an import mechanism
> later -- and furthermore, the only impact on existing extensions should we add
> such a mechanism would be that the extension authors must insert the
> importation lines.
>
> Therefore your proposal seems like a good step to take right now.  If I have
> described it accurately, +1.

I'm not so sure about my proposal now. Maybe we should always specify 
the parcel of imported types in .cfh files for now.

Nick

Mime
View raw message