Re: [lucy-dev] Clownfish interfaces

[Nick Wellnhofer <we...@aevum.de>]

On 28/12/2016 03:39, Marvin Humphrey wrote:
> Ruminating on my biases... I have found "fat pointers" hard to get used to
> because, honestly, I'm accustomed to casting of objects and containers without
> reallocation,

Even if fat pointers are two-element structs, they can be passed by value. 
There's no need for dynamic allocation.

> which imposes the requirement that objects be pointers and that
> all pointers be the same size.  Being able to cast `Obj**` to `Query**`
> without cost or with only CPU cost for run-time type checking is something
> that seems very natural.
>
> By now, I've done enough Go programming that the construct isn't as foreign.
> Still, the constraint that native Clownfish objects are struct pointers seems
> reasonable.

I still like the idea of fat pointers as an additional optimization. But it 
would be confusing to require an asterisk for normal objects (Obj*) but not 
for interface objects.

> This overview should be helpful:
>
>     https://en.wikipedia.org/wiki/Java_performance

This page seems to indicate that HotSpot uses a linear search over an array:

     https://wiki.openjdk.java.net/display/HotSpot/InterfaceCalls

But this probably isn't a performance problem for JVMs because of inline caching.

> The first approach seems closer to what Clownfish does now.  I think that's
> what you're leaning towards, right?  +1

I'd prefer the second approach but to accommodate languages like Rust, we'll 
probably have to go with the first option.

> Regarding backwards compatibility for Lucy, there is a certain amout of
> functionality which currently requires subclassing and overriding of methods.
> Off the top of my head, QueryParser, IndexManager, Schema, FieldType and
> Similarity all have such methods.

We should start with a list of classes that we officially allow to be 
subclassed now and that need to be reworked. In addition to the ones you 
mentioned, there are Analyzer, Highlighter, and Query/Compiler/Matcher.

> A general technique to solve this problem is to use composition: instead of
> expecting people to subclass IndexManager and override Recycle(), create a
> SegmentRecycler interface and allow customization through supplying a custom
> SegmentRecycler to IndexManager.

Another problem is that Deserialize and Load currently work on a blank object 
created with Class_Make_Obj. This would break with host-language interface 
objects but could be solved elegantly with class methods, i. e. methods that 
dynamically dispatch on a Class object. Instead of

     Query *query = (Query*)Class_Make_Obj(query_class);
     query = Query_Deserialize(query, instream);

we would write

     Query *query = Query_Deserialize(query_class);

Many dynamic languages like Smalltalk, Objective-C, Perl, Python, or Ruby 
support class methods, and it shouldn't be hard to support them in the 
Clownfish core. For languages like Go or Rust, we could create a separate 
interface hierarchy for class methods that are dispatched on singleton class 
objects. See this commit which is also useful for conversion from Clownfish to Go:

 
https://github.com/nwellnhof/lucy-clownfish/commit/30ed13800d10a3ff551a9f23ec288a04d5516911

Nick