lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject [lucy-dev] Specifiers of imported types
Date Tue, 17 Apr 2012 00:42:01 GMT
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.

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.

Marvin Humphrey

Mime
View raw message