Hi Tom,
Answering both emails here, in order:
> On 04/08/16 17:24, Tom Hacohen wrote:
>> Hey Gustavo,
>>
>> I am going to give a few comments, though it's really hard to review
>> like this. Although we are creating API here, we don't really care about
>> the API, we care about the usage. Which means, I don't care about how
>> the .eo file looks like, I care about how the .c file that uses it looks
>> like. You haven't provided that, so it means I have to guess,
>> misunderstand and work extra hard only to start a discussion that will
>> include more of the above.
indeed, I'll write some examples on the expected usage, would clarify
a lot indeed.
>> I don't really have much experience/knowledge
>> about this topic, but to me, for efficiency and clarity, it seems like
>> the best way to approach it would be to have a very simple wrapper
>> around read()/write() that handles address resolution, timeout, lifetime
>> and loop integration is enough. I don't think we should care about
>> binbuf or any other complicated setups, all we should get is a const
>> string (which is essentially a pointer to the static buffer with which
>> we called "read"), and then decide what we want to do with it on the
>> client side. Calling binbuf_append is not much work.
That's exactly what it is, a very thin one.
The blob/binbuf are important optimizations if we care about memory
consumption and reducing copies, but they are not mandatory. I'll
insist a bit more on them, but if it's the overall agreement to go
with buffer copies, then Okay.
>> All of this should be with simple eo callbacks. As you pointed out, this
>> is really a solved problem, I think most (all?) the frameworks and
>> languages do the basics quite the same. I'd follow suit, because I've
>> never had a bad experience with any. Keep the basics simple, and then
>> wrap as needed with a subclass (like for example, the send file cedric
>> suggested).
Problem is usually in the heavy usage, many are solved by using a
language that helps with reference count for you.
Like in Python, strings are immutable and one always keep references
to them. In other environments, it's COW, and your reference is kept
intact...
In C, if we use the easiest API (void* + size_t), we'll pay a price of
reallocs and memcpy :-/
>> 1. We no longer have a "constructor" just properties we mark as
>> constructing properties and sometimes are only allowed to set on
>> creation. In this case, since the real finalization is actually done in
>> "connect", we don't even need those, and can just have normal code there
>> that checks for those.
it's not a good usability to simply take the "setter" but have no
effect. If we can mark them as constructor-only, then it's much
better.
How to do that? Just use constructor { .property_name; } ?
>> 2. I'd also opt for strings for addresses rather than enum/types and
>> etc. Feels more correct.
ok, that one I already changed in my local copy to be sent later today.
>> 3. I'd also avoid promises.
ok
>> 4. As said, I'd keep it simple, so would avoid binbuf, and your blob
>> suggestion.
as per above, doable at the price of performance and memory consumption.
>> 5. There are a few naming issues, some have been pointed out.
what about others?
On Thu, Aug 4, 2016 at 2:14 PM, Tom Hacohen <t...@osg.samsung.com> wrote:
> I forgot one more thing, and also was asked on IRC for some
> clarifications about another, so here I am, replying to myself.
>
> A comment I forgot to make, which is to something cedric mentioned, and
> is something that I've said a million times already and I'll say it
> again because it's so damn important and people should stop doing it.
> Please do not delete objects implicitly. :( Connection is closed? Don't
> delete the object, I may steal be dealing with it. Let me eo_unref/del
> it if I'm still the rightful owner of the object, it's my
> responsibility. Maybe I still want to introspect it before it's gone?
> It's my decision to make... If you really think this pattern of
> autodeletion is useful, add a helper function people can add as a
> callback that just eo_dels an object. It's that simple.
Not really, I'm trying to use what is the standard and likely i got it
wrongly. I'm okay to add explicit events and methods to close the
socket, if that's what I should be doing :-)
I just wanted to use socket.close() if people were expecting to do socket.del().
Note that this shouldn't mess with refcounts, it's more like
evas_object_del() where you want the object to disappear immediately.
In this case the socket is not available anymore, so people should
stop using that after receiving the event.
> As for the clarification, I was asked to explain what I meant by
> "disagree with the concept". What I meant by that, is a "fatter" wrapper
> than thin. I just want a very thin wrapper, and I disagree with anything
> that's fatter. :)
As per above, I'm trying to have a very thin layer. The blob/binbuf
are ways to efficiently use memory in C.
BR,
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
