On Wed, Nov 17, 2010 at 00:24, Dan Stromberg <[email protected]> wrote: > > On Tue, Nov 16, 2010 at 8:38 AM, <[email protected]> wrote: >> >> On 04:27 pm, [email protected] wrote: >> >On Tue, Nov 16, 2010 at 4:17 AM, Antonio Cuni <[email protected]> >> >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/ _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
