On Fri, 14 Jun 2013 14:54:24 +0200 Jérémy Zurcher <jer...@asynk.ch> said:
> Hi,
>
> I'm still adding my bits to _eo_class_mro_add,
> the end is near.
>
> What do you think should be done,
> change a few, bin all , zillions or 1 phab rev, merge like a cowboy ??
actually... i'm more curious... you jumped in on eo pretty quickly after it hit
git... what do you think about eo in general? good/bad? before we start
building our universe around this... are there any really nasty things we
should fix before they are set in stone to retain api/abi? what could be done
to improve it and take it further over time to help people more?
stage 1 is pretty much done. current efl "classes" are mapped to eo and efl is
layered on top. stage 2 is to rebuild out classes/interfaces to make full use
of this so objects now inherit multiple interfaces/classes based on their types
(eg evas text objects would of course inherit basic eo interface plus evas
object geometry interface plus font set interface plus color set interface plus
text set interface - as a simple example (the same text set interface can then
be used on textblock objects and edje objects, and most/all elm widgets etc.).
so ultimately i expect to have this:
eo_do(obj,
efl_color_set(255, 128, 0, 255),
efl_font_set("Sans", 16),
efl_text_set("This is some text"),
efl_geom_pos_set(20, 30),
efl_visible_set(1));
maybe? well for sure so you don't need to now know if its evas_ or edje_ or elm_
or ecore_ etc. as namespace... just call something obvious on the object and
presto. all these interfaces need to be defined based on looking at current efl
and finding all the design patterns and turning them into common interface
classes.
keeping in mind that eo is not about replacing c++ but just bringing some of
the convenience of classes, interfaces and inheritance and methods to c, as well
as unifying our callback systems into a single one, making it easy to glue
objects together and have them auto deleted as a group. and of course providing
a safety barrier to separate apps and tools outside of efl with efl itself.
for now the eo id / table lookup is the layer we have, with it being mmaped
outside of normal libc malloc space so its hard to overwrite it. your madvise
stuff you put in so quickly was awesome btw, but over time i'd like to see us
also move more allocation for the insides of objects off into special memory
regions to improve this safety. the eo multi-call varags system lets us
increase this overhead with the eoid indirect lookup but then amortize that
cost over multiple calls, thus keeping us at an efficient level even with the
added work.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
