[KinoSearch] Feature request: overloading
Marvin Humphrey
marvin at rectangular.com
Wed May 20 16:18:09 PDT 2009
On Mon, May 18, 2009 at 04:06:52PM -0700, webmasters at ctosonline.org wrote:
> > There shouldn't be any public APIs which require the user to deal with an
> > I32Array. Presumably you've encountered one in an undocumented function?
>
> TermVector->get_start_offsets, ->get_end_offsets
Gotcha.
> Are you thinking of implementing the tie in C? If we do it in Perl,
> would that simplify things, or does its magic get in the way still on
> the C side?
We wouldn't implement the tie functions in C, they'd be in Perl. There has to
be a C element, though, because of the way that KS objects create and cache
their Perl objects from C.
However, I'm reluctant to add overloading to just I32Array. I don't like
overloading very much -- in my experience, it makes troubleshooting very
difficult, because you can't trust your ordinary debugging techniques. (For
instance, troubleshooting POD::Pom, which uses string overloading, drove me
bananas.) Hence my preference for conversion to real Perl elements.
KinoSearch::Doc uses hashref overloading, but Doc is kind of a special case.
If we were to add overloading to I32Array, I'd want to think hard and solve
this as an interface design problem generally for all integer arrays,
including BitVector -- because I don't want to inflict a rarely-needed,
half-baked overload API on the user base. I can't make time or brainspace for
that design discussion right now, though, because there are other tasks that
are more pressing and I32Array isn't even public. The current regime is good
enough for hacking on undocumented APIs -- and hopefully, the changes from
last weekend will have improved matters somewhat.
Marvin Humphrey
More information about the kinosearch
mailing list