On Thu, Aug 11, 2016 at 4:00 PM, Daniel Kolesa <dan...@octaforge.org> wrote:
> On Thu, Aug 11, 2016 at 12:30 PM, Davide Andreoli
> <d...@gurumeditation.it> wrote:
>> 2016-08-10 23:11 GMT+02:00 Gustavo Sverzut Barbieri <barbi...@gmail.com>:
>>
>>> ping... since this blocks some stuff I'm doing, will consider in
>>> agreement in 14h. :-)
>>>
>>
>> What I can say is that Eina_Slice is a bad name, should just be Eina_Buffer
>> or Eina_MemBuffer.
>>
>> And I tend to agree with raster to reuse the already available binbuf, if
>> it's feasible.
>>
>
> Slice is a good name, it's a slice of memory (without itself
> allocating said memory) and that's how this kind of stuff is commonly
> called in various places. However, I see another problem here, if we
> use mutable slices in our APIs, things are going to become difficult
> in our bindings... ideally, I would like all returned values from EFL
> APIs to be either immutable or alternatively owned by the caller (i.e.
> any writes in that returned value wouldn't affect any sort of internal
> state) and same with passed values, when passing EFL would either take
> ownership or make an internal copy for itself. Then any state changes
> would be done via Eo APIs. This way we can ensure bindings are super
> simple to generate and handle and it can even support languages that
> don't have mutability (like Haskell) very easily.

To bring more audience to the discussion started on IRC:

 * C provides: ssize_t read(int fd, void *mem, size_t len);

 * Python wraps to: buffer = os.read(fd, len) and an OSError exception.

Then I know what you mean with immutable stuff and with the example
above it's easy to know how that to manually map, it's easy. The
problem is how to let bindings know and do it right.

Assume:
interface Efl.Io.Reader {
    methods {
        read {
            params {
                @inout buffer: slice; [[provides the amount and where to read]]
            }
            return: Eina.Error;
        }
    }
}

NOTE that I've made buffer an in-out parameter, removing the "@out
used: size". Instead it will populate the buffer and change the size.

Bindings such as python could translate that to:

   cdef reader(self, size):
       void *mem = malloc(size)
       Eina_Rw_Slice rw_slice
       rw_slice.mem = mem
       rw_slice.len = size
       Eina_Error error = efl_io_reader_read(self.eo, &rw_slice)
       if error:
           raise eina_error_to_exception(error)
       mem = realloc(rw_slice.mem, rw_slice.len)   # may be smaller
than originally asked value
       return buffer(mem, rw_slice.len) # this is not the actual call,
just an example

-- 
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to