On Mon, 31 Dec 2012 18:18:10 -0200 Lucas De Marchi
<lucas.demar...@profusion.mobi> said:
> 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"
wth? so now you want to get pedantic with an rfc wording? there are not many of
them. comment was asked for long ago now. you chose not to. it's a bit late for
the "rip it out and don't do it at all" point. i'll repeat it here. if there
are things to improve and make better in eo - sure. make those points. let's
improve it.
> >> 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.
a very fundamental difference, but that may be lost on you.
> > 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.
you only lik the changes you make - as you understand them. others changes are
to be debated long after the opportunity for debate is over.
> > 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.
i'm continuing from the logic of "change is bad so roll it back". most of your
complaints are just that.
> > 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.
i listed a long list of things as to why eo fits the bill. i gave a list of
things we need. it provides solutions. you do not provide them.
> >> 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.
it does more than gobject, and does other things very differently to gobject so
it can get these features to work. i never intended efl to become so big and
general. i made a few small libs an they piggybacked on eachother so e17 could
be written, and then they basically grew. way too much. if i had known efl
would be as big and expansive as it is now and used as it is, i would have put
in an object system from the ground up, not just a half-done one for evas.
if your complaint is "i just dont like object systems in c" then we're never
going to make your happy, and so debate is pointless. we have problems. i
started hunting for solutions. we threw about ideas to the solutions on irc and
so on over a period of maybe 1-2 years before eo kind of put them together.
once put together they were more coherently asessable.
> > 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.
and what is do bad about this? this is what c can do. c is flexible. it's not
some rigid ivory tower were you must follow some specific ethos or design
pattern.
> > 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.
it would have made debugging much more mysterious.
> > 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.
it an be done and tbh probably should. then it's easy to identify and contain
the new stuff and old stuff.
> 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
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of 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_122512
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
