[Sugar-devel] [FEATURE] Create an adapter that calls the third parties/libraries for better maintainability.
tonadevv at gmail.com
Sun Feb 10 20:14:54 EST 2019
Can you give me a link to an example where it's applied?
I don't know if I was clear. I was talking about something more "global".
Like a new package at the sugar repository, that way any activity can use
it. All the calls to Gtk (for example) are changed with the adapter in all
the activities and then only the adapter will change in case of an update.
On Sun, Feb 10, 2019, 6:55 PM Walter Bender <walter.bender at gmail.com wrote:
> We do that to some extent -- for example, there is an "adapter" for
> collaboration and at one point we discussed doing the same with other
> "adapters" I use in the bulk of the activities I wrote -- abstractions of
> the various GTK classes. But it never go that much traction from the rest
> of the dev community.
> On Sun, Feb 10, 2019 at 7:19 PM Alejandro García <tonadevv at gmail.com>
>> TLDR; Why not creating an adapter that calls the libraries/third parties
>> that we use creating activities (like GTK, WebKit, etc) and in the
>> activities we only call the adapter? For more information read below.
>> I was a participant at GCI 2018, I worked mostly porting to GTK3,
>> WebKit2, and TelepathyGLib.
>> Time ago I read the book "Clean Code - Robert C. Martin", there he (Uncle
>> Bob) talked a little about using Adapters (what I mean for adapters are
>> files with methods and classes that call the libraries for us. And we
>> instead call the adapter instead of the library/third party) when using
>> third parties. That way you can use the third party in all the app, but if
>> there is an update in the third party you only need to change one place
>> (the adapter).
>> After reading that, I thought how easy could it be if there were an
>> adapter for Gtk, WebKit, and TelepathyGLib instead of changing all the
>> instances of them in each Activity.
>> Basically that's the proposal. Why not creating an Adapter for the
>> libraries that are used in mostly all the activities like GTK and start
>> using it from all the sugar activities.
>> - The maintainability of the projects could be easier, as you only need
>> to change one place in case that the library gets an update (probably
>> useful in case of porting to GTK4 in a future, I think its release is going
>> to be at the end of this year).
>> - Developing new activities could be easier too, learning GTK (or any
>> other library) won't be necessary at all.
>> Probably there are more advantages that I'm ignoring.
>> - Creating this adapter will require time and people, and this can sound
>> like reinventing the wheel. But the dependency to the libraries/third
>> party, will be reduced.
>> Again there might be more disadvantages that I'm ignoring.
>> I think that's all. If you have something to say, don't doubt to do it. I
>> want to know what you think.
>> This is the first proposal that I do to an organization. If there is a
>> template that I didn't follow or the Feature tag is incorrect, please tell
>> me and I can rewrite this mail.
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
> Walter Bender
> Sugar Labs
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel