POLL: anyone like new refactoring proposal?
Hi All,
I wonder if it is just me lacking inline type parameter refactoring.
This should substitute type parameter for its erasure, search for all
instantiations and insert casts where needed,
and safe delete the parameter. The whole process took more than 5 minutes
for me yesterday with the class with not so many usages.
Anyone with similar experience/expectations?
Best Regards,
Eugene.
Please sign in to leave a comment.
Yes, of course. I'm always in favor of new refactorings. Refactorings are half of what makes this product great. I haven't needed this one yet, but I undoubtedly will someday.
--Dave Griffith
IHMO IntelliJ has enough java refactorings for the moment.
Much more important would be to have more refactorings for other
languages than java, since most of the real projects contain not only
java files:
- Javascript
- CSS
- Html/xhtml
- jsp
- xml
IMHO having refactorings for the above file types, would bring much more
user efficiency and gain(and product value over the concurrence) than a
few more refactorings for the already very well covered java.
Just my 2 cents,
Ahmed.
+1 There definitely is a need for more refactorings (as you can see from
my Change Type plug-in).
Tom
"Ahmed Mohombe" <amohombe@yahoo.com> wrote in message
news:d3oahu$bmr$1@is.intellij.net...
And your suggestions for those languages refactorings? What exactly do you
miss when editing those languages that we can automate through
refactorings?
Friendly,
Eugene.
In article <d3ogv0$dmd$1@is.intellij.net>,
"Eugene Vigdorchik \(JetBrains\)" <ven@intellij.com> wrote:
Well speaking for JSP specifically, I would like to see support for
scriptlet refactoring to the same level as java is now. But that's
already planned. Also would like to see special refactoring where you
can pull some scriptlets into custom tags and help with the process of
creating the custom tag... that's planned too I think.
As far as HTML, I would like to be able to highlight a block of html and
move it to another html so we can refactor ui interfaces quicker.
For CSS, it would be nice to be able to create a new css and have an
introduce css where you'd cascade a change across jsps and html pages.
If you rename a css item, then have it change the css and
cascade to all the files.
R
I do agree: I find it much more important that IDEA provides somewhat "predictable" behaviour when editing a non java file than new features in the java editor. I mean: when I press ctrl-b on a custom tag this moves to the tld. That's good. When I press ctrl-alt-b nothing happens: this is no good, it could move to the class implementing the tag. When I press ctrl-q on the tag the "description" in the tld is shown. But if I press it on a tag attribute this does not happen: inconsistencies, and lack of good response to "since ctrl-? does this in the java editor then I expect it to do... in the XXX editor" are weak points, that could be perceived as a poorly refined product.
Change Java with the mentioned and than you have a big list.
Of course not everything fits for everything, but alot.
Maybe you could start with some sort of "find usages/references" since
this was the begining in java too (CodeSearch in 2000, right? ).
Everything! At the moment, there's almost nothing, so when working in
Idea with java files than opening another type(html/js/css/jsp/xml),
suddenly the the "fiendly and intelligent IDE that understands the code"
dissapers.
Ahmed.
+1
We code a lot here, but 80% of what we do has a web front end.
The 3 non-web developers use JBuilder (2) and Eclipse/IntelliJ
The 6 web developers use IntelliJ (4), JBuilder (1) and Eclipse (1<-
poor guy is having fits with JBoss development)
With that said, we are all moving to JSP 2.0 ASAP. The language is so
much more powerful, but the editor is sorely lagging far behind the
language it self and even further behind the editor support that is
available in .java files.
Robert S. Sfeir wrote:
>In article <d3ogv0$dmd$1@is.intellij.net>,
>
>
>>"Ahmed Mohombe" <amohombe@yahoo.com> wrote in message
>>news:d3oahu$bmr$1@is.intellij.net...
>>
>>
>>>IHMO IntelliJ has enough java refactorings for the moment.
>>>Much more important would be to have more refactorings for other
>>>languages than java, since most of the real projects contain not only
>>>java files:
>>>- Javascript
>>>- CSS
>>>- Html/xhtml
>>>- jsp
>>>- xml
>>>
>>>
>>And your suggestions for those languages refactorings? What exactly do you
>>miss when editing those languages that we can automate through
>>refactorings?
>>
>>
>
>Well speaking for JSP specifically, I would like to see support for
>scriptlet refactoring to the same level as java is now. But that's
>already planned. Also would like to see special refactoring where you
>can pull some scriptlets into custom tags and help with the process of
>creating the custom tag... that's planned too I think.
>
>As far as HTML, I would like to be able to highlight a block of html and
>move it to another html so we can refactor ui interfaces quicker.
>
>For CSS, it would be nice to be able to create a new css and have an
>introduce css where you'd cascade a change across jsps and html pages.
>If you rename a css item, then have it change the css and
>cascade to all the files.
>
>R
>
"Ahmed Mohombe" <amohombe@yahoo.com> wrote in message
news:d3ok5j$t27$1@is.intellij.net...
A little bit of boasting:)
Well, we already have succeeded in that (I mean goto definition and
highlight usages). It is either in 3290 or will be available in the next
build.
Rename files/directory/web directory should also work correcting references
in e.g. jsp.include or html href attributes.
So the basic functionality is there, we are talikng about more advanced
features.
As for java refactorings, it's my passion to do some features that are not
requested now,
but when you find them some day, you have a really nice suprise:)
Eugene.
Okay, more detail now that I've got more time. IDEA at present covers about 98% of my automated refactoring needs. If you're really looking to polish that last 2%, here's the things I've felt the lack of, or think I someday might.
1)Improve "Extract Method" and "Inline Method". Most of the gap here is in dealing with multiple return points, or (inversely) cleaning up after inlining some stereotypical method categories. Short version here is that you should be able to extract sequences of statements with multiple returns if either that sequence cannot complete normally, or if the fact that the sequence returned normally or not can be captured as a boolean return value. Inversely, you should be able to inline any method created like that even though it has multiple returns.
http://jetbrains.net/jira/browse/IDEABKL-2139
http://jetbrains.net/jira/browse/IDEABKL-854
Always frustrating when you expect these to work and they don't.
2)Improve "Extract Variable/Field/etc." for associative operations
http://jetbrains.net/jira/browse/IDEABKL-2132
and also for extracting substring selections. As with 1), these are frustrating because you expect them to work, and it's jarring when they don't.
3)XML refactorings: change tag to attribute, change attribute to tag, extract entity, inline entity, remove attributes, rename tag, rename attribute, remove tag, remove attribute, remove attribute matching value, add attribute to tags, add tag to tags. Yes, these all can be done with SSR (or XSLT). They would be vastly friendlier as built-in refactorings with nice drop-downs and such. Also should be available in various scopes.
4)Inline Type Parameter as described, and the inverse Extract Type Parameter (which should actually even be more useful). These are reasonable things to expect in a JDK1.5 refactoring IDE.
5)Inspections for limiting local variable lifetimes
http://jetbrains.net/jira/browse/IDEA-547
6)Convert top-level class to inner class
6)JSP refactorings. A low priority only because it's for my team-mates rather than me. Start with the ones in the Irida list, and then see if any more are necessary.
7)Refactoring to patterns. Batch up some of the other refactorings and code generation into higher-level pattern constructs. Stuff like "Add Observer support to class", "Package operations as Commands", and "Create Visitor for classes". With a bit of creativity, the "Wow" factor could be quite high for a fairly low level of effort.
--Dave Griffith
I'm convinced of that. In fact all IntelliJ users are nice surprised
from time to time do discover a new gem :).
But as spoiled java refactorings/(intelligent IDE) users (that want to
use the IntelliJ shortcuts even in Word :) ), editing other file types
is a real pain.
Ahmed.
Hi,
+1 for these two
Francesco
8) Integrate Change (variable/parameter/method return value) Type
refactoring.
Tom
I have never needed this functionality. I think there are more important
refactoring RFE's that should be implemented before this one.
Some of the possible JSP refactorings I think can lead to the same 'wow' factor that initial versions of IDEA did.
For example, 'extra tag file' around a scriptlet, which would automatically check the outputs and inputs, and create an appropriate .tag file (inputs would become variables etc). Some others:
Replace scriptlet bean access with EL: <%=pageContext.get("foo")%> -> $
Extract SimpleTag
Find code duplicates across jsp files, with the option of moving them to an include
rename javascript function
Ahmed Mohombe wrote:
I second that. Before more Java refactorings, being able to use the
language wizardry that IJ introduced to the world on JavaScript would be
great.
I am working in OO JavaScript which is fairly similar to Java after one
removes some type safety and language dependency (a.k.a. imports), and
adds features such as runtime class virtual table modification.
In order to replace Java imports there would have to be some IntelliJ
constructs (e.g. JavaScript libraries of .js files).
Amnon
....and pressing Ctrl-W to mark an word is deadly in MS Word :)
Ahmed Mohombe schrieb:
How about also thinking about "batch" refactoring operations. E.g. Copying all selected classes to another package? I have had to do this recently and I could not find an easy way of doing this.
Copy and paste isn't enough?
-> Package View, select classes, copy, go to destination, paste.
What more do you want?
In article <eef42a967c3c88c7134857b786e4@news.intellij.net>,
Carlos Costa e Silva <carlos@keysoft.pt> wrote:
Documentation to know he can do that :D
R
Hi Eugene,
I could have used this refactoring a couple of times (indeed, yesterday I had wished such a refactoring existed...). I admit that with being relatively new to using Generics, I have more than once "overdone" it and had decided later the code would become more readable by dropping a type parameter and using "old school" class casts instead. So to me an "inline type parameter" refactoring would be a useful tool for code simplification.
Regards
Jan