On Tue, Sep 25, 2012 at 12:19 PM, Marvin Humphrey <[email protected]> wrote: > 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. :(
Happily, I do find this statement obvious. If we need an accessor method because we are doing some sort of lazy evaluation, it should be used. But you may be right about the difference in perspectives. The question is whether we ever want to allow direct access to instance variables, from inside or outside a parcel. I'd be happy with disallowing out-of-hierarchy access, and probably OK with a default of privacy, but don't like not being able to allow direct access. I don't think we'd be well served by having user defined subclasses always have less access than the core classes. Blurring the distinction between the two forces us to have a API, since we're forced to use it ourself. I think the philosophical difference is that I'd be comfortable with distinguishing in-class from out-of-class, but don't like privileging by parcel. I also don't like the idea of requiring accessors unless they serve a useful purpose, as in the case you describe. >> 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. That's certainly the manner I would prefer, and might work for the specific case of the demo, but I don't see how that is possible in general. Perhaps you could remake his demo in that manner once the API settles? > 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. We're back to agreement! Yes, it's an injection framework that would solve this, not direct access to instance vars. :) > 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. OK, I'll drop it here. I've registered my uneasiness, and if it's unconvincing then proceeding with Nick's proposal is probably the best plan. --nate
