On 12/31/2012 06:15 AM, Cedric BAIL wrote: > 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. eo_step has been committed in revision 80760. Check the log to understand how it works. > >>> -- >>> 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 >
------------------------------------------------------------------------------ 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
