On Mon, Dec 31, 2012 at 12:24 PM, Henrique Dante <hda...@profusion.mobi> wrote: > On Sun, Dec 30, 2012 at 9:28 PM, Cedric BAIL <cedric.b...@free.fr> wrote: >> On Sun, Dec 30, 2012 at 12:06 AM, Henrique Dante <hda...@profusion.mobi> >> wrote: >>> While developing with Eo I also noticed that it breaks cscope usage. >>> Whenever I wanted to jump to the definition of some method call, I >>> reached a macro in the include file instead. Then I had to use the >>> method ID to do a new search, this time not by definition, but by >>> usage in class definitions. >> >> It took me time to understand what you mean by definition. My > > A definition is a declaration that includes the element's content.
Your definition is still vague when speaking about macro, prototype and implementation. >> understanding of your complaint is that you don't like virtual. cscope > > The way you are saying suggests that I don't like some part of object > orientation, which is false. I was strictly referring to the > implementation of Eo and its influence on development. > >> will never be able to find the implementation (for me definition is > > Method calls that were not polymorphic, from concrete classes, were > made polymorphic with Eo. And in this case, polymorphic means > explicitly referenced by an ID. That's the virtual I didn't like. But > even if I liked it, it would have broken "jump-to-definition" the same > way. Jump to declaration is not broken and provide documentation, prototype for said call. That what developer using EFL are looking for. > The problem you mentioned was restricted to a (small ?) subset of > methods, the ones derived from base classes. Now the whole libraries > have this problem. > >> the prototype, that's why I was confused) at compile time, because it > > That's a declaration. > >> is determined at runtime. The same problem exist with C++ and people > > No idea how that's done in C++. I think cscope works with C++ by > luck. However in an OO language, a method call bound to a concrete, > "bottom-of-hierarchy", instanced object should be enough to jump to > its definition, at compile time, even if the method is virtual (this > should only be harder if it's necessary to walk through the object > hierarchy). Anyway, jumping to definition of a virtual method with > cscope on a C++ project can be done with 1 search, not 2. So now, I don't follow you anymore. Jumping to the prototype of a virtual in C++ work exactly the same way it work in C. At least from an user of the API. I think I now do understand what you mean. You are doing development inside EFL and try to find the macro that correspond to a function implementation, right ? As a matter of fixing that issue, couldn't you not instruct csope to do the double jump for you ? It doesn't sounds like the problem is more a limitation in your tool than a real issue. >> think that virtual is useful somehow. > > Not sure why you're talking about the concept of virtual. My comment > was about noticing that developers might avoid EFL because Eo (not OO) > has negative effects on development. Maybe because your explanation is confusing. I was supposing you were writing application with EFL and did use the EO API and where complaining about that. Now I think you are trying to work inside EFL with EO API and are complaining about some limitation of your tool. >> In fact we need virtual today in EFL for at least to case, for at >> least to case that I know of. First geometry get on Evas_Object_Text >> and second for all the *_file_set that lurk around, have the same >> prototype and do the almost the same think, but just exist to confuse >> the developer. > > That looks like there are too few cases to consider it as a benefit. That's just the two first example that came to me without having the need to search for anything. I am sure there is more. Making a non virtual and virtual function call would have added a layer of complexity and risk for API/ABI break later. It's a trade-of . > Repeating again, I sent the comment to sugest that Eo could have a > negative acceptance by developers. It was difficult to understand the context of your remark. Now, I think you are trying to get used to EFL source code and Eo is another bit of complexity in that picture. I guess you never looked at GObject :-) In all object model implemented in C, there is some boiler plate like that. Eo come with its own. >>> The other way doesn't work well either: >>> single stepping in gdb to find out the code path or looking at a >>> backtrace are both polluted with Eo calls. In general single stepping >>> on an efl method call should take 5 seconds, but with Eo it may take 5 >>> minutes. Main negative conclusion about this is that there's no >>> trivial way to find out what an Eo call does, and this will discourage >>> new developers from reading code. >> >> Did you try Daniel's gdb script for that task ? > > No idea what it is. efl/data/eo/eo_step.py. >> -- >> Cedric BAIL >> >> ------------------------------------------------------------------------------ >> 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 > > There's a Microsoft ad in your e-mail. Oh, look below, there is one also for your message ! You are pretty new here, right ? :-) >> MVPs and experts. ON SALE this month only -- learn more at: >> http://p.sf.net/sfu/learnmore_123012 >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ > 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 -- Cedric BAIL ------------------------------------------------------------------------------ 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
