On Mon, Sep 24, 2012 at 10:28 PM, Nathan Kurz <[email protected]> wrote:
> On Mon, Sep 24, 2012 at 3:09 AM, Nick Wellnhofer <[email protected]> wrote:
>> I think we're going a bit in circles here.
>
> Not exactly circles. I suggesting that we go back to the last fork
> and check our map, so that we're sure that we're on the right road.
I don't know. I feel like we are very, very far apart on the question of
information hiding[1], and I don't think either of us is going to make any
headway persuading the other. We may or may not end up going in circles, but
we will be off-track for a long time.
> [from earlier]
>> Note that my approach doesn't work with cross-parcel access of member
>> variables, not even with accessing member vars of superclasses if the
>> superclass comes from another parcel. But I think that's something we could
>> live with.
>
> I don't see this as acceptable, although both you and Marvin seem to
> view it as partially a positive.
Right, because it improves encapsulation.
>From _Design Patterns_:
Because inheritance exposes a subclass to details of its parent's
implementation, it's often said that "inheritance breaks encapsulation".
A classic example: lazy loading.
int
Base_get_doc_id(Foo *self) {
if (!self->up_to_date) {
self->doc_id = Base_calculate_doc_id(self);
}
return self->doc_id;
}
If a subclass accesses `doc_id` directly rather than going through
Base_get_doc_id(), it will get the wrong number.
If instance variables are hidden by default, that forces users to go through
the accessor, yielding correct behavior 100% of the time.
That this was not obvious illustrates how different our perspectives and
priorities are. :(
> My feelings come from two separate
> directions:
>
> 1) While this might be acceptable for Lucy, if we were treating
> Clownfish as a separate project I think this would leave it dead in
> the water. I don't think that a general purpose object hierarchy
> system would be well served by not allowing a user defined child class
> to have easy access to the class it inherits from.
If you are writing a class that is designed to be subclassed, it's not a big
deal to provide some accessors.
Even better, focus on interface design rather than code reuse when designing
the superclass. If you can achieve your goals without instance variables or
non-abstract methods, that greatly reduces the problem of inheritance
breaking encapsulation.
> To focus on something specific, consider Peter's custom scoring demo:
> http://www.mail-archive.com/[email protected]/msg00249.html
>
> What would it take to write this as a compiled extension rather than
> an interpreted one?
If Peter modifies that demo to use composition instead of inheritance, it gets
a lot simpler and does not require access to instance variables at all.
If Peter leaves it as a subclass of TermQuery, though, the copied-and-pasted
code for calculating TFIDF weights remains a nightmare regardless of whether
vars are accessed directly or via accessors.
Marvin Humphrey
[1]
http://en.wikipedia.org/wiki/Information_hiding#Example_of_information_hiding
