lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: Payloads
Date Thu, 21 Dec 2006 19:10:26 GMT
Michael Busch wrote:
> Yes I could introduce a new class called e.g. PayloadToken that extends 
> Token (good that it is not final anymore). Not sure if I understand your 
> mixin interface idea... could you elaborate, please?

I'm not entirely sure I understand it either!

If Payload is an interface that tokens might implement, then some 
posting implementations would treat tokens that implement Payload 
specially.  And there might be other interfaces, say, PartOfSpeech, or 
Emphasis, that tokens might implement, and that might also be handled by 
some posting implementations.  A particular analyzer could emit tokens 
that implement several of these interfaces, e.g., both PartOfSpeech and 
Emphasis.  So these interfaces would be mixins.  But, of course, they'd 
also have to each be implemented by the Token subclass, since Java 
doesn't support multi-inheritance of implementation.

I'm not sure this is the best approach: it's just the first one that 
comes to my mind.  Perhaps instead Tokens should have a list of aspects, 
each of which implement a TokenAspect interface, or somesuch.

It would be best to have an idea of how we'd like to be able to flexibly 
add token features like text-emphasis and part-of-speech that are 
handled specially by posting implementations before we add the Payload 
feature.  So if the "mixin" approach is not a good idea, then we should 
try to think of a better one.  If we can't think of a good approach, 
then we can always punt, add Payloads now, and deal with the 
consequences later.  But it's worth trying first.  Working through a few 
examples in pseudo code is perhaps a worthwhile task.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message