Hi,
On Tue, 2013-02-05 at 17:14 +0900, Tristan Van Berkom wrote:
> Reduce code in ESourceExtension implementations
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I like this idea, even the implementation would be a bit tricky, as I
would keep those set/get/dup functions in the extension's public API.
It's part of the nice thing on it, right?
I added couple new properties to source extensions already and it's
nothing but a copy&paste boring monkey work. While it'll still be a
copy&paste job, its extent would be significantly limited with some base
struct support for this purpose. Similarly with the mentioned property
mutex, which is now part of each descendant which requires it, and might
be "doubled" in subdescendants.
> CrackPot crazy idea of code sharing
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This one I won't support. Thinking of it the libraries are linked
dynamically, thus there is (almost?) none binary duplication.
I'd rather like to see addressbook-specific source extensions residing
in addressbook/libebook, calendar-specific source extensions residing in
calendar/libecal, and those common in libedataserver (as they all are
now). Backend specific extensions are backend specific.
A little bit of file placement cleanup.
Bye,
Milan
_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
