On 25 May 2016 at 20:48, Daniel Kolesa <dan...@octaforge.org> wrote: > On Wed, May 25, 2016 at 12:29 PM, Jean-Philippe André <j...@videolan.org> > wrote: > > Hi q66, > > > > It would be good to keep pointer support for void*. These APIs would be > > limited to C (and maybe C++) only. > > I have the evas image native surface in mind, as well as the gfx buffer > > map/unmap. > > > > Again, this is only for C/C++. Maybe a @native tag could come along? > > If that's not possible, we need to go back to EAPI for those, and handle > > the class hierarchy manually, somehow. > > > > The use cases for native pointers should be very limited. > > I don't think that's feasible, as it puts a burden on the Eolian API > where not necessary - if we really need those, we can simply introduce > a hardcoded builtin for them (which the C generator will handle > specially) - this way it wouldn't have any special API requirements. > But ideally even for stuff like evas image native surface I would like > to come up with a way to map it to everything, I'm just not entirely > sure yet how. >
Yes, a special builtin type is fine. The only thing is that generators other than C need to know to skip this method / property. > > > > On 25 May 2016 at 20:01, Daniel Kolesa <dan...@octaforge.org> wrote: > > > >> Hello, > >> > >> I've started removal of support for pointers in Eolian in order to > >> bring the language one level up and make it easier to do bindings. > >> This has already been done for class handles and for complex types > >> like array, hash, iterator etc. but currently one big obstacle in the > >> way is strings. I have a pretty clear idea in my head but it's > >> possible I might have missed something so I'm asking here if anyone > >> has any feedback or ideas or whatever that I could have missed before > >> implementing it. > >> > >> Basically my idea currently is to introduce a new "string" builtin, > >> which ALWAYS represents const char *. Mutable char pointers will not > >> be possible with this system - I believe we don't want these either, > >> because they're low level and represent something that you can change > >> but not resize, plus it doesn't map well to various languages, > >> especially scripting ones. I did some analysis on our API and it seems > >> we actually have very few uses for mutable char pointers - there is > >> currently only a handful of cases across the EFL, as opposed to > >> countless const ones. APIs that currently use mutable char pointers > >> would be dealt with on per-case basis and redesigned, probably to use > >> something like Eina_Strbuf (in most cases; strbuf will get another > >> builtin eolian type) with wrappers for legacy. > >> > >> Another thing is stringshares - I'm considering introducing another > >> builtin for that, but maybe that won't be necessary. I gotta > >> investigate more - again, there's only a handful of cases across the > >> EFL anyways. > >> > >> Overall, removing pointers will benefit probably everyone, I believe. > >> For one it will mean that there won't be any need to map pointer types > >> to higher level languages in generators; another thing is that it > >> means death of nested types in Eolian, which will make manipulation of > >> types with the API much simpler. > >> > >> If you have any objections or notes, please bring them up. Otherwise, > >> I will proceed with my approach. > >> > > > > As for the rest, I think string and no pointers anywhere is a great idea. > > > > Regards, > > > > -- > > Jean-Philippe André > > > ------------------------------------------------------------------------------ > > Mobile security can be enabling, not merely restricting. Employees who > > bring their own devices (BYOD) to work are irked by the imposition of MDM > > restrictions. Mobile Device Manager Plus allows you to control only the > > apps on BYO-devices by containerizing them, leaving personal data > untouched! > > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > ------------------------------------------------------------------------------ > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of MDM > restrictions. Mobile Device Manager Plus allows you to control only the > apps on BYO-devices by containerizing them, leaving personal data > untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Jean-Philippe André ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
