Browse Prior Art Database

A Comprehensive Approach to Handling Types, Names, and Accessibility in Refactoring Disclosure Number: IPCOM000202763D
Publication Date: 2010-Dec-29
Document File: 3 page(s) / 68K

Publishing Venue

The Prior Art Database


Disclosed is a comprehensive approach to handling types, names, and accessibility in refactoring in response to the need for a more robust refactoring tool. The invention introduces JL, a lookup-free, access control-free representation of programming language programs in which declarations are not referenced by their name but by a unique label, without any lookup or access control rules. With translations from the programming language to JL and vice versa, refactorings can be formulated directly at the level of JL.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 3

A Comprehensive Approach to Handling Types , Names, and Accessibility in Refactoring

Refactoring is the process of applying behavior-preserving transformations, themselves called refactorings, to a program's source code in order to improve its design [1, 2]. Over the past decade, automated tool support for refactoring has become available for mainstream programming languages, and popular integrated development environments support a growing number of refactorings. However, even such industrial tools are still quite fragile, and often refuse refactoring applications or render refactored programs uncompilable. As a result, despite an evident need for refactoring in software development, acceptance of refactoring tools seems to be lagging [3].

The fragility of present-day refactoring tools is largely due to the fact that these tools have to analyze and transform programs at the source level, which is significantly more challenging than working on some convenient intermediate representation as compilers do. Source level programs contain many features such as nested classes, method overloading, and access modifiers that require great care when applying program transformations; writers of compiler optimizations simply do not have to worry about these.

This is particularly evident for refactorings that manipulate programs at the level of declarations. For one programming language, a declaration has three principal components: a name, a type, and an accessibility. Each of these is governed by its own set of intricate rules and well-formedness conditions which a refactoring has to respect: lookup rules specify to which declaration a name binds, access control rules decide whether a declaration is accessible at a point of reference, and typing rules determine whether the type of a declaration fits its usage throughout the program. Since declared types are just names, lookup and access controls directly affect type correctness. Conversely, the type of a declaration can affect lookup, through, for example, method overloading resolution.

Therefore, refactorings such as "Extract Interface" and "Pull Up Method" not only require preserving subtype-relationships between the types of certain program elements, but may also require changing the accessibility of declared entities, qualification of names, and inserting casts on method arguments to preserve program behavior. Refactorings of this kind are very important since declarations constitute the interfaces between classes, and thus play a pivotal role in the design of object-oriented systems.

Previous work has addressed the three main components of a declaration in isolation; yet no comprehensive solution exists that addresses all of them in a common framework. In particular, the work on constraint-based refactorings by Tip [4, 5] and Steimann and Thies [6] provide complementary, but incomplete solutions. The former does not consider access control; whereas, the latter does not take type-related...