JDK-6194740 : Abbreviate code when using constants as method parameters
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-11-12
  • Updated: 2006-11-21
  • Resolved: 2006-11-21
Related Reports
Relates :  
JDK-6191812 - Ability to use qualified enums in case statements
Description
A DESCRIPTION OF THE REQUEST :
I often write the following long and finger-tiring piece of code:

  myLabel.setFont(myLabel.getFont().deriveFont(Font.BOLD));

but would like to write

  myLabel.changeFont(BOLD);

This report is essential two related feature requests aiming at reducing unnecessarily verbose code:

(1) Where a method such as deriveFont(int) takes a constant from class Font, we shouldn't need to have to write
  font.deriveFont(Font.BOLD)
but instead just
  font.deriveFont(BOLD)
since it can only take constants from the Font class so "Font." can be assumed.  This applies to any method parameter that takes a fixed constant value.

(2) Shortcut method on Component to replace the
  setFont(getFont().deriveFont())
with
  changeFont(size, and/or style, and or family)
This is just a specific example of simplifying user code at little cost

JUSTIFICATION :
It would make code shorter and closer to what the brain understands is the intended behaviour.

component.changeFont(BOLD)

is easy to understand at a glance and is unambiguous from the compiler's standpoint because the changeFont() method parameter would be tied to the Font.BOLD / ITALIC / NORMAL constants.
###@###.### 2004-11-12 17:44:39 GMT
Comments
EVALUATION (1) This issue can be resolved by using 'import static' statement. For example: import static java.awt.Font.*; ... component.setFont(new Font("Dialog", PLAIN, 10)); ... (2) There are several reasons why changeFont() is considered as not a good idea: - there is already too much 'syntax sugar' and legacy API (like show/hide/setVisible, resize/reshape/setLocation/setSize/setBounds, etc.) - fonts are immutable, so changeFont may be confusing - Graphics class also uses get/setFont - changeFont is not very bean-like So I'm closing this change request as 'Will Not Fix'.
21-11-2006
EVALUATION Responding solely to part (1) of the Description: Methods should obviously use enums in JDK1.5 and greater, rather than static primitive constants. So, suppose a Font enum is defined with constants BOLD,PLAIN,etc, and the setFont method takes a Font enum as its parameter. The submitter would still have to pass Font.PLAIN. They would prefer to pass PLAIN and have the compiler infer that the formal parameter type (enum Font) provides a scope for the PLAIN actual parameter. This would be a neat little trick but would be complicated if 1) there is already a variable called PLAIN (possibly of the enum type Font) in scope, and 2) setFont is overloaded (what if enum types E1 and E2 both declare a PLAIN constant, and there are setFont(E1) and setFont(E2) signatures accessible?). Compile-time method resolution is complicated enough already without introducing a special case for enum arguments. Consequently, I am denying the request to be able to 'abbreviate' static fields and enum constants. In this examples here, the 'Font.' qualifier will continue to be required. Part (2) of the Description concerns java.awt, so I am dispatching the request there.
08-11-2006
EVALUATION The problem is that nowhere in the compiler readable specification does it say that the int constant should come from the Font interface, and since it is just an int, any equivalent int would do just as well. And, if Component.changeFont(int) were added to the API, where would the compiler determine that the constant should come from the Font API. The better long term solution is for APIs to use the typesafe enums, instead of ints, in cases like this, and that is one of the reasons why enums were provided. ###@###.### 2004-11-12 18:24:44 GMT
12-11-2004