Hello!
PCMan has written on Tuesday, 9 April, at 23:43:
>On Mon, Apr 8, 2013 at 11:32 PM, Andrej N. Gritsenko <[email protected]>
>wrote:
>> PCMan has written on Monday, 18 March, at 11:50:
>>>I'm afraid that the multiple-backend design is overly-engineered.
>>>Though it looks much more flexible, there is no real-world use cases
>>>since we don't mix multiple image libraries in one GUI project. For
>>>example, you won't use both of QImage and GdkPixbuf in a Qt project,
>>>and vice versa. I'm not against making things flexible, but if there
>>>are no valid real-world use case, I prefer KISS.
>> Well, it have rights to be once-set, of course, but any good design
>> should have errors checking code. If you look into my letter (arghh, that
>> top-posting again!) then you can see I've written that I don't like the
>> possibility to accidentally overwrite data which will be left unnoticed.
>> Therefore we have to have error check in fm_thumbnail_loader_set_backend
>> function and return some error code instead of void return. Am I wrong on
>> that?
>Then we can make it return gboolean and check if the backend functions
>have already been set. If it's already set, we prohibit overwriting
>the old function table and returns FALSE. Is this OK for you?
Completely OK! Thank you very much!
>>>> And I also think fm_thumbnail_result_* isn't good name for the API.
>>>> Result is an item literally and fm_thumbnail_result_cancel() sounds very
>>>> odd. How can we cancel result? We can cancel task, request, whatever is a
>>>> process, only process is cancellable, not item which we got. Therefore I
>>>> think there should be better name for this API family. What about, for
>>>> example, fm_thumbnail_loader_*? That should look better I believe, and
>>>> also it unifies all names (part of them are fm_thumbnail_loader_* now but
>>>> part are fm_thumbnail_result_*).
>The proposed fm_thumbnail_loader() name unfortunately is already taken
>and used in other places. To avoid name clashes, I named it
>*_result_*.
>Please see fm-thumbnail-loader.[hc] files.
Let's see. The ambiguous names are:
a) fm_thumbnail_result_cancel() - fm_thumbnail_loader_cancel() is nowhere
used;
b) fm_thumbnail_result_get_*() - fm_thumbnail_loader_get_*() are nowhere
used.
And the whole fm_thumbnail_loader_* namespace is used only in those
fm-thumbnail-loader.[hc] files and nowhere else, so there could be no
name clashes! And file name fm-thumbnail-loader.[hc] suggests it defines
namespaces fm_thumbnail_loader_* and FmThumbnailLoader*, isn't it?
>It's true that the naming is bad but I'm not able to come up with a
>better one at the moment.
>In xmms2 client library, they call pending result of async calls
>"result". That's where I got the idea. In Qt, the naming is more
>weird. They call it "future" since the result will be returned in the
>"future". So there is a C++ class named QFuture in it, which I
>consider very odd.
>Any better suggestion about the naming/wording here?
I still prefer to have single unified fm_thumbnail_loader_* namespace
instead of two - fm_thumbnail_loader_* and fm_thumbnail_result_*. Also it
may be reasonable to change FmThumbnailResult into FmThumbnailLoader and
have namespaces unified to exclude any possible misunderstandings. Does
that look reasonable for you too?
With the best wishes.
Andriy.
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Pcmanfm-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
