On Sun, Dec 30, 2012 at 11:33 PM, Carsten Haitzler <ras...@rasterman.com> wrote:
> 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.
It's the same logic Mike applied. That was not a "RFC: generalizing
all objects with a single one"
>
>> 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".
for me "not listening" is the same as disagreeing here.
>
> 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".
ohhhhh, who is clueless now? I am the changer guy. I love changes. The
good ones, not just because we can.
>
> 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.
I am impressed by your lack of arguments now bringing up this.
>
> 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".
I said "don't be silly" because you are twisting the words and facts
to justify adding eo.
>
>> 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.
oh... now I see one of the reasons why I don't like it... it's gobject
on steroids.
>
> 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
this has all to do with my complaints. And it's one major argument against it.
> 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
this would have being even worse.
> 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.
I never said abi has been broken. but yes, the api did. If this solves
the breakage, then IMO it should be applied.
Anyway, I am off the discussion now. Now I understand Gustavo's
approach and I will do the same... wait and see. And avoiding that
code as much as I can.
hey, and happy new year to all :-)
Lucas De Marchi
------------------------------------------------------------------------------
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
