On 06/11/13 00:35, Felipe Magno de Almeida wrote:
> n On Tue, Nov 5, 2013 at 7:02 PM, Tom Hacohen <t...@stosb.com> wrote:
>> That is not going to change.
>>
>> The first and most important reason is that we are *NOT* going to break API
>> no matter how right you are.
>
> OK. Can't really argue with that. Though I don't really see how an application
> that depends on this behavior for *prepend_relative functions to be correct
> since it just doesn't prepend relative to NULL at all.
If you really want to nit-pick, our lists and double-linked lists, so
the NULL is on both sides which means this is actually doing exactly
that (well, except for the fact that it replaces the NULL).
Well, applications were allowed to depend on that because it is
explicitly written in our docs. Even if you think it's wrong. Even if it
wasn't in the docs, it's relied upon in many places, so again, changing
it is a no go.
>
>> The second reason is that we also have append_relative and having two
>> functions that do the same would be redundant.
>
> I don't see how that is related to what I said. I only want to prepend, but
> I want the relative argument to treat NULL as a valid position in the list
> (being that the post-the-end position), instead of treating that as an
> optional argument with a fallback for list prepend algorithm. We already
> treat NULL as an empty list and the list ends when next points to
> NULL, so it already is true that NULL *is* the post-the-end node.
It's related because then what would you do with the append_relative
functions? Will they behave the same way as the prepend_relative (when
null is past as the relative)?
>
> Also, using post-the-end positions is idiomatic in C and C++.
> int = 0;
> for(i = 0; i != size; ++i)
> {
> // loops on all elements
> }
I disagree with this example, I don't see how this has anything to do
with null and double-linked lists.
>
>> The third reason is quite subjective, and maybe I'm too used to the efl
>> way, but I would expect the default behaviour of prepend relative to be
>> prepend. That's why I'm prepending.
>
> If NULL becomes a valid domain for the positional argument, then
> there isn't a default to talk about. Only prepend to relative argument
> where NULL means the position after the last element. The list
> argument already includes NULL in its value domain for eina list
> functions.
>
> Also, not append, nor prepend can be used to insert
> elements in all possible positions of a list. Prepend can't insert
> the element after the last element and append can't add it as
> a first element. There's no current algorithm that can be used
> as a
Again, double-linked list, NULL is in the list twice. Sure prepend and
append can't both be used to insert everywhere in the list, that's
annoying. As I said, the last point is subjective, maybe I was wrong
(still not convinced I am). However that doesn't change the fact that
it's not going to change. :)
>
>> Anyhow, talking about it is moot as this is not going to change.
>
> Ok. I won't bring it up again if there's no controversy on this.
Even if there was, it's not going to change (recurring theme).
I understand developing libraries can be annoying, especially if you are
a perfectionist (I'm one as well). However that doesn't change the fact
that we've made a promise to our developers, and that promise is our
API. We are not going to break that promise no matter how big the
controversy is.
--
Tom.
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
