Improving IDEs through Better Encapsulation and Organization

I don’t want header files that show just “public” methods and attributes, I want to filter what gets displayed in the main code window.  I might start out by only seeing the public methods.  Then, if I’m extending a class, for example, I might want to see the protected methods as well.  In either case I might just want to see the prototypes and their documentation comments — not the code.

On the other hand, if I’m working in a file, making changes, and I feel a method is getting over complicated, I might want to break it up into a few methods.  With a standard IDE, assuming I want a well-organized file, I have a couple choices: I could put this new function, right under the method that calls it (which works well if this new method is only going to be called by this one other method); or, I could put it in a “private” section at the bottom if the new method might be used by other methods in this file.  I could do other things to depending on the exact circumstances, but in any case there are a couple problems I see.  Let’s assume this new method is only to be called from the one other method.   First, I don’t care about this method when I’m browsing this file unless I’m specifically concerned about the method that calls it.  Second, I need to come up with some commenting or organizational mechanism or just remember that these two methods are connected.  That is, there’s no signal indicating a hard connection and to the IDE, the method call and the name of the new method are just pieces of text.  Something  that might help would be a drawing a box around the two methods and having the code of both be hidden unless specifically told otherwise.  In addition, the prototype for the new method could be hidden or ghosted as its secondary.   Lastly, I should be able to query the second function to see what methods call it and I should be able to query the first method to see which methods it calls.

The encapsulation offered by current languages and IDEs is too manual of a process.  I don’t want header files that show just “public” methods and attributes, I want to filter what gets displayed in the main code window.  I might start out by only seeing the public methods.  Then, if I’m extending a class, for example, I might want to see the protected methods as well.  In either case I might just want to see the prototypes and their documentation comments — not the code.

On the other hand, if I’m working in a file, making changes, and I feel a method is becoming overly complicated, I might want to break it up into a few methods.  With a standard IDE, assuming I want a well-organized file, I have a couple choices: I could put the helper methods right under the method that calls them (which works well if this new method is only going to be called by this one other method); or, I could put them in a “private” section at the bottom if the new method might be used by other methods in this file.  I could do other things too depending on the exact circumstances, but in any case there are a couple problems I see.  Let’s assume this new method is only to be called from the one other method.   First, I don’t care about this method when I’m browsing this file unless I’m specifically concerned about the method that calls it.  Second, I need to come up with some commenting or organizational mechanism or just remember that these two methods are connected.  That is, there’s no signal indicating a hard connection and to the IDE, the method call and the name of the new method are just pieces of text.  Something  that might help would be a drawing a box around the two methods and having the code of both be hidden unless specifically told otherwise.  In addition, the prototype for the new method could be hidden or ghosted as its secondary.   Lastly, I should be able to query the second function to see what methods call it and I should be able to query the first method to see which methods it calls.

In summary, what I’m looking for in an IDE are the following: keeping track of actual relationships between functions and variables such that tools can be developed to facilitate the automatic reorganization (at least of the appearance) of code and the querying of the relationships between pieces of code.

Advertisement