On Sat, Feb 13, 2021 at 3:15 PM Daniele Nicolodi <[email protected]> wrote:
> On 13/02/2021 20:12, kuba jamro wrote: > > From my perspective, it would be nice if there was at least one fully > > maintained importer to help people start and in my mind that's a coin > > toss between CSV and OFX. > > I agree that it is nice to have an example importer, however, for this > to be effective in illustrating how to write an importer it should be as > simple as possible while being feature complete. The CVS importer has a > ton of code that has nothing to do with writing an importer but only > with jiggling CSV field values around. > > > If it were not for the CSV importer in the source tree, I would not have > > discovered the Mixin's which now feature in most of my importers. > > One thing Martin and I discussed briefly is to get rid of the mixins. > Mixins remember me of the old days in which I was hacking on the Zope2 > codebase, but they can be replaced by easier paradigms (as testimonies > what happened to most of the Zope2 codebase...) > Indeed. Mixins are opaque. I really don't like using them. When you look at your class, it's not immediately obvious which implementation of which method is picked up and what it contains. (Abstract inheritance is the only good kind of inheritance; the opacity that concrete inheritance brings is just never worth it in my experience.) I'd much rather we provide a library with one-liner invocations to it you cut and paste in each importer. > > Which Mixins do you find useful, and why? > > Currently, an importer is a class that implements 6 methods (one of > which is optional). The use of the mixins, in my opinion, makes the code > more complex without much benefits. > > > As progress seems to be going in the direction of splitting out source > > into repos specific for their responsibility, I would be pretty happy if > > the importer(s) had its own and perhaps all the importer helpers were > > also in their own library repository. > > New repository come with non zero overhead in maintenance and > coordination, especially in a phase where we are redesigning the > interfaces. I would wait to see i > > > Martin suggested exactly that and that seems to be the most versatile as > > developers would only need to clone the repo if they actually needed it. > > As you cannot run an importer withou beangulp, I don't think this would > save anyone anything, and the beangulp codebase is really tiny. > > Cheers, > Dan > > -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/9aa781e7-229f-18f9-4a52-8c307e8b5240%40grinta.net > . > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhNKz9nW6DUE7uUio0C%3DS%2BqNd9aOwWLARzwPRmn_kT%3Ds5g%40mail.gmail.com.
