On Sun, 30 Dec 2012 14:19:01 -0200 Lucas De Marchi
<lucas.demar...@profusion.mobi> said:
> On Sun, Dec 30, 2012 at 12:51 PM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
>
> > i shall start with a single one: 'Subject: [E-devel] Eobj - Request for
> > review/comments' in april 2012.
>
> indeed I missed that. But don't be that silly. Let me explain:
wait. you challenge me to provie even 1 example (there's more) and now you
dismiss it by saying "don't be silly"? this line of logic i fail to follow.
> I just added a project under PROTO/ named ldm with features X, Y and
> Z. Will you review it? probably not.
if you said "we want to make this the future of all oo infra in efl" and asked
for input, i would.
> 5 month later later I come back and replace all your Eo structs
> underneath you with my ldm structs, because this is the way I think is
> the right way. Will you complain? Of course you will.
that is nothing like what happened. not even close. you have many opportunities
to have input, comment etc.
> To worse, it was added together with the move of the tree to efl/. And
> I *DID* complain saying there was no reason to rush eobj in. Of
> course you didn't hear because a patch like eobj would be impossible
> to maintain out of tree.
indeed it would be impossible - saying i didn't listen is just your way of
saying "you disagreed therefore i will say you didn't listen". you even provide
a justification for disagreing here, and yet... you decide it's "not listening".
what i see here is "there is a change, and i don't like change. i hate change.
change means i have to adapt and i hate doing that".
i suggest we roll back the async rendering code in evas. it's change. it
creates problems. it hasn't solved anything. oh - and edbus. it's change. it's
created leaks and crashes and soaked up my time during my vacation. let's roll
it back. i hate change.
don't be silly. this is EXACTLY what you sound like. you'd now just pulling
justifications out of the air to back a desire for "no change".
> And as others pointed out, saying "this has been discussed on IRC and
> mailing list" and interpreting that like "it has been decided to do
> this way" is just silly.
there were 2 main lines of how to solve our "oo stuff". gustavo's which was
"just use smart objects" which i said wouldn't fly because we can't make lower
level objects use this (timers etc). they are also too heavy-weight for such
uses even if we twisted the world. evas canvases then can't ve objects either.
they also do not support multiple inheritance (or multiple interfaces) which i
listed as a requirement because elm was literally creating objects that did
this (scrolled entry for example). i had requirements that went roughly like
this:
1. support normal single inheritance
2. multiple inheritance must work sensibly
3. we have to be able to go down to ecore and make timers etc. into objects
4. we have to be able to attach objects to eachother weakly or tightly (weak
refs or strong refs)
5. we need to clean up our callback prototype mess and unify
6. we need to make object ptr (handle) access much safer in the event of freed
objects or errant (garbage) pointers as well as typechecks
7. since #6 probably is going to raise object access overhead, some way of
alleviating this would be really nice
8. we have to be able to slide it under our current api/abi so "stuff keeps
working as it used to" but in future we can migrate to it once slide underneath
everywhere
9. support runtime method overriding etc.
10. unify the data attaching we have (evas_object_data_set/get/del)
11. allow for memory compaction/gc to alleviate fragmentation
i think i had a few more. some were more important that others, but
multiple-inheritance was a big one as it was problematic with just stuffing
struct in struct methods of single inheritance gobject did.
eo wasn't even created yet. there were toy attempts/exampels in different forms
etc. to explore ideas and see what would work or not but nothing concrete. this
was the time to have a say. even with the first iterations of eo - it was the
time to have a say. eo solves the bove, OR lays the groundwork to be able to
solve the above transparently under the hood in future.
now you claim eo adds all sorts of problems. the eo_do() is impractical. i just
don't get that. it's just as practical as now.
obj = evas_object_image_add(evas);
evas_object_image_filled_set(obj, EINA_TRUE);
evas_object_file_set(obj, "blah.jpg", NULL);
evas_object_move(obj, 0, 100);
evas_object_resize(obj, 200, 100);
evas_object_show(obj);
very common thing in code. with eo
obj = eo_add(evas_object_image_class_get(), evas,
evas_obj_image_filled_set(EINA_TRUE),
evas_obj_image_file_set("blah.jpg", NULL),
evas_obj_position_set(0, 100),
evas_obj_size_set(200, 100),
evas_obj_visibility_set(EINA_TRUE));
how is that impractical to use? how is it ugly?
i've already said that eo_do is not ioctl() - it's vastly different since it
doesnt rely on passing in magic struct ptrs filled in from prior call code and
is NOT 1 eo_do == 1 operation.
backrace - yes. that's what happens if you slide in a layer. if you slide in
any layer no mater what it is it'll add to the bt. arguing against this is
arguing against any chnage at all to code that may possibly add another call.
that means you argue for no change every - no unification. no shared common
layer OR no compatibility. that's a bogus argument. yes - it adds 2 layers.
this can be alleviated inside eo. just make it macros or diectly copy & paste
the code. the perfromance argument was one that went around a lot and we
investigated and looked into and he whole varags thing was a way of addressing
it.
eo to some very minor extent does kind of "invent a new lang" within c. i
mulled the idea of an added pre-processor at compile time to be able to add
things like namespacing and cutting down typing fluff but others rejected the
idea. it didn't happen - ok. fair enough. it'd be c PLUS some efl speciic
"language extensions" in a preprocessor much "smarter" than cpp. c++ would
entail a massive change much more invasive than eo and it'd come with other
side-effects too like the complaints of build times and memory needed just to
build efl from eveyr dev. your complaints herew oudl jsut morph into other
peoples complaints about this.
the smart object thing i've already addressed. you have a very narow veiw if
all u think is smart objects. this had to solve more than evas, thus its not
viable
for the loglevles - agreed here isnt a need for eo to be so noisy log-wise.
this is at least useful and constructive feedback and something easily
addressed.
and we've had our disgreement on if its api or abi breakage. we could solve
this with ifdef CPLUSPLUS stuff... but then it wouldn't get access to any of
the eo infra in parallel - it'd have to stick to the old api and types only. at
this stage it hasn't ben done - i'd like to hear from andreas about this since
he was he one affected. i am thinking we possibly should split the headers
anyway right now - "old efl" stuff and the new eo stuff. #include them from
the master "Evas.h" etc. etc.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
