[pypy-dev] gdbm

[Paolo Giarrusso]

On Wed, Nov 17, 2010 at 00:24, Dan Stromberg <drsalists at gmail.com> wrote:
>
> On Tue, Nov 16, 2010 at 8:38 AM, <exarkun at twistedmatrix.com> wrote:
>>
>> On 04:27 pm, drsalists at gmail.com wrote:
>> >On Tue, Nov 16, 2010 at 4:17 AM, Antonio Cuni <anto.cuni at gmail.com>
>> >wrote:
>> >>Sounds fine, do you feel like implementing it? :-)
>> >>
>> >>Moreover, I also agree with amaury that your code is very similar to
>> >>the
>> >>one in the current dbm.py, so we should maybe try to refactor things
>> >>to
>> >>share common parts between the twos.
>> >I'd be happy to.
>> >
>> >Would sharing based on inheritance or a more functional approach be
>> >preferred?

>> No, avoid inheritance where possible.  Composition is preferred.

> Due to performance?  Or "flat is better than nested" - as more of a
> philosophical issue?  I'm not arguing for inheritance, just wanting to
> understand the reasoning behind it.

I answer on this because it is a general topic.
Preferring composition over inheritance is a general design principle,
not intended to improve performance; of course, there are cases where
inheritance is good, so it needs to be further qualified; but in a
very simple way, inheritance is often used where it is not
appropriate.

One of the reasons which come to my mind is that inheritance implies
closer coupling between subclasses and superclasses. If you look for
"composition vs inheritance" on Google, you will find quite a few
articles. One which looks good is this one:
http://www.artima.com/designtechniques/compoinh4.html
(you can also browse the whole article, I link to page 4 because it's
more interesting).

That article also points out that you might get some performance
overhead with composition instead of inheritance, which is the
opposite of what you said, and that makes some sense; however, in many
cases the overhead can be removed by an optimizer through inlining,
and that's one reason not to worry. The other reason not to worry is
that the overhead is anyway minor and thus design issues are more
important - doing otherwise would be premature optimization.

If you have a lot of experience with hard data which taught you that
you should avoid something upfront, and that data is still valid, then
you can avoid something upfront - and that's not the case here,
because when you change your target implementation, you'll need to
recheck about how it optimizes, and that takes long.

>> As for "functional", I don't really know what approach you're describing
>> with that word.

> I mean something like what you'd do in Lisp, ML or Haskell (not that I know
> any of those that well).  I suppose in this case it would mean
> functools.partial() as a decorator, or perhaps a wrapper around
> functools.partial() used as a decorator.

> Then again, maybe functools.partial() imposes its own performance penalty?
> That's part of why I'm wondering if avoiding inheritance is a
> performance-related goal.

I can't comment in detail on this, because I just had a look at the
code - but performance shouldn't be the main goal.

Anyway, it looks like most differences are about calling clearerr or
not, and about the module name in strings; probably one could abstract
that away through some other technique.

Bye!
-- 
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/