On Mon, Dec 31, 2012 at 2:15 AM, Cedric BAIL <cedric.b...@free.fr> 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.
I'm not a big fan of discussing terminology. My definition is C definition, so we shouldn't be discussing this. > >>> 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 Correct, but it jumps to the abstract (base) declaration, not to the derived one, even with a bottom level object with its own implementation. > 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 ? Yes, I was not worried about the prototype, I needed the implementation. > > 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. I'd do a script for that, or more probably, will avoid reading the code. > >>> 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. To make things simpler, ignore my second paragraph. I explicitly stated that this was something "I also noticed", but you ignored the first paragraph and focused in trying solve my specific problem, instead. Even if you convinced me that what's broken are my tools, this is not about me. > >>> 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. Since you understood what I'm saying, there's no point on trying to solve the issue for me. Anyway, gtk widgets implements their methods by themselves and the API has multiple entry points. They don't route the methods through a gobject message builder. > >>>> 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 ? :-) I'm happy that you didn't ask me to patch my browser to deal with this issue. > >>> 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
