Relative scopes: is this possible?

The scope editing feature in the various search actions is great; however, there's one thing I miss: a limited scope, relative to the class/item I'm searching for.

For example, I might be looking at the Hibernate sources, and want to search for usages of EntityPersister usages only in Hibernate itself. This happens a lot when I'm browsing third party source code: to understand how something works, I have to search for usages a lot, and I'm only interested in usages inside the library itself.

In other words, I'd love if IDEA had a built-in scope called "containing library" or something similar. Is there any way to achieve this, today?

8 comments
Comment actions Permalink

Create custom scope for the library you are interested in (press ... in
scope chooser of Find Usages dialog).

Marcus Brito wrote:

The scope editing feature in the various search actions is great; however, there's one thing I miss: a limited scope, relative to the class/item I'm searching for.

For example, I might be looking at the Hibernate sources, and want to search for usages of EntityPersister usages only in Hibernate itself. This happens a lot when I'm browsing third party source code: to understand how something works, I have to search for usages a lot, and I'm only interested in usages inside the library itself.

In other words, I'd love if IDEA had a built-in scope called "containing library" or something similar. Is there any way to achieve this, today?



--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0
Comment actions Permalink

Create custom scope for the library you are
interested in (press ... in
scope chooser of Find Usages dialog).


I know, what I'm asking about is a way to do this without having to create a scope for all 23 libraries I usually browse the source.

These "relative scopes" could have other uses, too -- like limiting the actuation scope of refactorings relative to the elements being refactored.

0
Comment actions Permalink

Marcus Brito wrote:

These "relative scopes" could have other uses, too -- like limiting the actuation scope of refactorings relative to the elements being refactored.


I don't know about that. If I have references to a method that I'm
renaming which are outside of the relative scope I have defined then it
will break the code. Refactorings must encompass the full scope in which
the target element can be referenced. The whole point of refactoring is
to make changes without breaking the code.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

0
Comment actions Permalink

Actually, there are cases where you do want to limit your refactoring:

- Projects where you are not allowed to modify other modules.
- When you want a quick idea of how much (if any) breakage an interface restructure would cause in other modules before proceeding.

--
Maarten

0
Comment actions Permalink

I don't know about that. If I have references to a
method that I'm
renaming which are outside of the relative scope I
have defined then it
will break the code.


My point exactly. You may be refactoring code used by modules which you don't have permission to change. If this happens, and you really need to refactor, your only option is to break things. People responsible by the now broken code will make the necessary changes later (hopefully they'll get a warning from you first).

the target element can be referenced. The whole point
of refactoring is
to make changes without breaking the code.


Sometimes you must break things to make them anew ;)

0
Comment actions Permalink

Maarten Hazewinkel wrote:

- Projects where you are not allowed to modify other modules.


But if those modules have references to the thing which you are
refactoring, you'll break them. What's the point?

- When you want a quick idea of how much (if any) breakage an interface restructure would cause in other modules before proceeding.


And you can see that by previewing the refactoring and checking if any
references are in the other modules. Without changing and breaking code.

I really see no need for it.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

0
Comment actions Permalink

Marcus Brito wrote:

My point exactly. You may be refactoring code used by modules which you don't have permission to change. If this happens, and you really need to refactor, your only option is to break things. People responsible by the now broken code will make the necessary changes later (hopefully they'll get a warning from you first).


I prefer a less combatant approach to inter-team interaction ;)

Sometimes you must break things to make them anew ;)


Meh. You can do that without introducing new features to help you do it.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

0
Comment actions Permalink

I prefer a less combatant approach to inter-team
interaction ;)


Me too, but sometimes our evil, hellspawned corporate managers won't let us take a softer approach. I miss working on a smaller company sometimes.

0

Please sign in to leave a comment.