You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2012/04/17 02:42:01 UTC
[lucy-dev] Specifiers of imported types
On Mon, Apr 16, 2012 at 4:36 PM, Nick Wellnhofer (Created) (JIRA)
<ji...@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
Re: [lucy-dev] Specifiers of imported types
Posted by Nick Wellnhofer <we...@aevum.de>.
On 17/04/2012 18:07, Marvin Humphrey wrote:
> One way I hope to build on your work, though, is breaking out the fundamental
> clownfish types into a separate parcel.
Yes, a lot of work in that direction has been done :)
> I don't think it's acceptable to run
> through every .cfh file in core changing every instance of Obj to cfish_Obj --
> and therefore, this problem continues to block that goal.
This seems to be one of the biggest remaining road blocks. We'd need at
least something like the *_USE_SHORT_NAMES macros for .cfh files.
Nick
Re: [lucy-dev] Specifiers of imported types
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Apr 17, 2012 at 8:36 AM, Nick Wellnhofer <we...@aevum.de> wrote:
> Maybe we should always specify the parcel of imported types in .cfh files
> for now.
So the declaration for MyTokenizer#Equals would look like this, then:
public bool_t
Equals(MyTokenizer *self, lucy_Obj *other);
I think that ought to suffice as a workaround. If there are not any other
problems, then absolutely that is the fastest detour around this roadblock
rather than hacking on CFC's type validation in order to get your extension
building and running.
One way I hope to build on your work, though, is breaking out the fundamental
clownfish types into a separate parcel. I don't think it's acceptable to run
through every .cfh file in core changing every instance of Obj to cfish_Obj --
and therefore, this problem continues to block that goal.
Marvin Humphrey
Re: [lucy-dev] Specifiers of imported types
Posted by Nick Wellnhofer <we...@aevum.de>.
On 17/04/2012 02:42, Marvin Humphrey wrote:
> On Mon, Apr 16, 2012 at 4:36 PM, Nick Wellnhofer (Created) (JIRA)
> <ji...@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