On Wed, May 25, 2016 at 1:34 PM, Tom Hacohen <t...@osg.samsung.com> wrote: > On 25/05/16 13:11, Daniel Kolesa wrote: >> On Wed, May 25, 2016 at 12:53 PM, Tom Hacohen <t...@osg.samsung.com> wrote: >>> On 25/05/16 12:01, Daniel Kolesa 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. >>> >>> evas_image_pixels_get returns a const char * that's not a string iirc. >>> Or heck, maybe char *. It's a good idea to also have a buffer type for >>> just dumping of raw data. This is useful for image pixel manipulation >>> and etc. >>> >>> Strbuf: overkill, avoid it. I wouldn't bother. >>> >>>> >>>> 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. >>> >>> Waste of time and unnecessary increased burden on generators. >> >> You mean reduced burden - as then they can just directly emit calls to >> stringshare APIs without going through another layer. > > Thank you for the attempted correction, but I mean increased burden, > because that's yet another type they need to take care of.
They need to take care of it either way, just in a different, more complicate way. > > -- > Tom. > > > ------------------------------------------------------------------------------ > 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
