RE: [cdt-dev] Heads-up: A new renaming UI tool

[Douglas Schaefer <dschaefe@xxxxxxxxxx>]

Thanks, Leo,

Comments below.

Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada

cdt-dev-admin@xxxxxxxxxxx wrote on 03/11/2004 09:48:35 AM:

> I don’t think that this functionality should be added to CDT at this
> time.  I’ll explain why, but first, let me digress…
> 
> This is simply my opinion and you can attach whatever weight that 
> you want to it.  I’m not trying to upset anyone, but I AM trying to 
> change the priorities of the team.
> 
> I think that CDT currently has enough “code-assist” functionality. 
> Sure, more is better, but adding more need not be a priority.
> 

An interesting circumstance of the way eclipse.org is organized is that 
all of us work for companies that take Eclipse and integrate it into their 
products (whether internal or external). As such, our priorities are 
mainly driven by those product plans. We build features to enhance those 
products and we contribute them back with the hope of encouraging others 
to do the same. That way we all benefit for each other's efforts and build 
something none of us could do individually. That's the real beauty of open 
source.

This functionality that Hoda has built was built for an IBM product and we 
have decided to contribute that work back to the CDT. We will make sure it 
doesn't degrade the quality of the CDT and we hope the community will find 
it useful.

> In my personal opinion, there are 3 important issues with CDT that 
> would keep me from recommending that Intel C++ customers use it 
> (This is not to suggest that I ultimately make that decision…). 
> 
> 1. Lack of complete functionality in the build system:  This has 
> been discussed a lot, and I think that this will be the easiest 
> problem to fix.  I’m not criticizing the idea, the design, or the 
> current implementation.  It’s simply that not enough resources have 
> been applied to it.

You are absolutely right. This is why I am encouraging participants in the 
CDT, especially those that depend on build in their corporate products, to 
work in this area. This is the best way they can ensure their needs are 
met and is the only way things will improve for all.

> 2. No support for different vendor C/C++ language variants:  My 
> concern, directly related to Hoda’s proposal, is that when parsing 
> fails, all of the “code-assist” functionality may be broken.  Hoda, 
> how certain are you that there are not cases where your renaming 
> functionality will do the wrong thing (without the user being aware 
> that it has done the wrong thing) when parsing/searching fails?

I can let Hoda respond, but we will make sure this functionality comes 
with an undo manager so that if build errors do arise after a refactoring, 
the user can quickly undo them.

As we close out 2.0, if we find it doesn't meet our quality standards, we 
still have the option to turn it off.

> 3. Scalability with large projects with respect to code-assist 
> functionality.  I saw a few mails from Thomas Fletcher in February 
> that suggest to me that there are serious problems.  After my own 
> review of the CDT design last Fall, I have always been concerned 
> that there is too much parsing and other reading of source files (e.
> g. indexing) going on.

Thomas's issues were with 1.2.x which had a different code assist 
architecture and were related to the performance of the search engine. A 
lot of these issues have been addressed. We are also looking at 
performance issues with the parser in 2.0 right now and have fixed a 
number of areas where we saw problems. We will continue to be vigilant on 
performance.

There are some interesting options I am investigating to improve the 
architecture of the parser/indexer/AST to help with scalability and 
accuracy going forward. We'll get there and in the short term we are 
putting every effort into ensuring what we have works well in real world 
environments.

> 
> Numbers 2 and 3 look like hard problems and need to be solved together.
> 
> In summary, with respect to Hoda’s proposal, I don’t think that new 
> “seed”s for additional code-assist functionality should be added 
> when the foundation to support it is not solid.
> 

Thanks, Leo. We appreciate your input as always and encourage your 
participation to help ensure your priorities are met. If everyone's 
priorities are taken care of, we will all reap in the rewards.

> Regards,
> Leo Treggiari
> Intel Corp.
> 
> -----Original Message-----
> From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] 
> On Behalf Of Hoda Amer
> Sent: Tuesday, March 09, 2004 10:12 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] Heads-up: A new renaming UI tool
> 
> 
> Hello everyone, 
> 
> I have been working on a new UI tool for renaming model elements. It
> relies on search in finding all occurrences of a specific model 
> element and changes the found occurrences in the code to a new name.
> It could be invoked by a menu item in the C/C++ Packages view. 
> 
> I have used the basic architecture of the JDT refactoring, but 
> simplified it to a great extent. In JDT, refactoring has many 
> specific options depending on the renamed element. It also has an 
> undo manager and a sophisticated preview page. Further, JDT has 
> defined refactoring as an extension point such that participants 
> could change its behavior if they wish. 
> 
> The new tool does not have all of this. It just has a simple preview
> where the user can choose to apply changes to a whole file or skip 
> that specific file. It totally depends on search, so its correctness
> is fairly high. It is not too sophisticated and it does not have an 
> undo manager; however, it can be viewed as a seed that could be 
> added to later to develop a solid refactoring tool. 
> 
> I am still testing the tool, but I am planning to submit it soon. I 
> am interested to know what everyone thinks about this. 
> 
> Regards, 
> Hoda Amer
> Staff Software Engineer
> Rational Software - IBM Software Group