On Nov 20, 2007, at 12:18 PM, Peter Karman wrote:
I see from recent KS commits that you are refactoring to use inside-
out
objects. I know that's a fairly hot design choice these days for Perl.
Inside-out objects are typically touted for three reasons. From
<http://www.perlfoundation.org/perl5/index.cgi?inside_out_object>:
* Option to enforce privacy.
* Proper namespacing for member variables.
* Isolation from implementation details.
The first point, enforced privacy, is not a concern. In fact, the KS
flavor of inside-out uses "our" rather than "my" variables to
facilitate introspection and debugging.
The second point, proper namespacing, is kinda nice, but hash-key
typos aren't really a problem within the KS code base -- yay for Vim
auto-complete. :) Typos in parameter labels are always a concern,
but the inside-out model doesn't offer any advantage there and KS has
other means of dealing with those.
It's the third point that makes all the difference.
With the inside-out pattern, we can take a C struct based on
Boilerplater, stuff it into a blessed scalar ref and enjoy nearly all
the advantages of traditional Perl objects. So we have something
extremely usable from C and highly usable from Perl.
In contrast, a typical hash-based Perl object is extremely usable
from Perl... but quite awkward to use from C. Perl objects can't be
used polymorphically from C in place of Boilerplater objects. You
have to wrap the Perl object in a Boilerplater object and override
every method you want to use.
Recent changes to KS have made it much easier to call back to Perl
(or potentially any other host language) from C. Right now,
MockScorer is the exception, but soon all KS classes will follow its
model: base classes written in C which may be subclassed using either
Perl or C.
Are you finding it makes it easier to do things with XS, C and the
reference counting?
Object destruction is a huge issue and has been one of the hardest
things to get right. KinoSearch::Util::Nat, which will become
KinoSearch::Obj, solves many problems by caching a Perl object at
construction-time and relying solely on the Perl refcount. This is a
big enough topic that I'll post about it separately.
Another advantage lies in unifying the OO structure of KS. Right
now, there are two different kinds of KinoSearch classes: those with
a C struct at their core, and those with a Perl object at their
core. Having only one type of object will make things easier for a
variety of reasons.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
