[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-ui-dev] requesting input re: Java model changes for 1.5
|
Agree with Dirk. If the resulting code patterns start to look too painful,
it's relatively easy to add aggregating versions of them (i.e."
isClassOrEnum"), but if we hide the distinction up front, then it's much
harder to add it back later.
McQ.
Dirk Baeumer <dirk_baeumer@xxxxxxxxxx>
Sent by: jdt-ui-dev-admin@xxxxxxxxxxx
11/03/04 03:47
Please respond to
jdt-ui-dev
To
jdt-ui-dev@xxxxxxxxxxx
cc
Philippe P Mulet <philippe_mulet@xxxxxxxxxx>
Subject
Re: [jdt-ui-dev] requesting input re: Java model changes for 1.5
Hi Jeem,
I definitely prefer option 1 (all predicates are mutual exclusive).
Getting
something for
free (as with option 2) which doesn't properly work in all cases makes is
harder to find
bugs. So we should be forced to enable the new features where is makes
sense.
Dirk
Jim des Rivieres
<Jim_des_Rivieres
@ca.ibm.com> To
Sent by: jdt-ui-dev@xxxxxxxxxxx,
jdt-ui-dev-admin@ jdt-debug-dev@xxxxxxxxxxx
eclipse.org cc
Philippe P Mulet/France/IBM@IBMFR
Subject
03/03/2004 09:58 [jdt-ui-dev] requesting input re:
PM Java model changes for 1.5
Please respond to
jdt-ui-dev@eclips
e.org
We'd like your input on an issue above how to evolve the Java model APIs
for dealing with 1.5 features.
As you probably know, in JDK 1.5, there are 2 new kinds of type
declarations: enums, and annotation types.
Enum declarations are for defining enumeration classes. They look like
public enum Color {RED, GREEN, BLUE};
Annotation type declarations are for defining annotation types, which are
used in annotations. They looks like:
public @interface JLSRef {
public int edition();
public float section();
}
Both enum and annotation type declarations can be more complex than the
examples show; for example, the
body declarations for enums can include constructor, method, and regular
field declarations. Enum declarations are like class declarations with
minor syntactic changes ("enum" instead of "class") and some restrictions
(no superclass can be specified; restricted body declarations). Annotation
type declarations like are interface declarations with minor syntactic
changes ("@" before "interface") and some restrictions (no superclass or
superinterfaces can be specified; restricted body declarations).
The question is what is the most effective way to evolve the Java model
API to deal with these newcomers. In the Java model API, IType is used to
represent types. There are a pair of mutually exclusive predicates,
IType.isClass() and IType.isInterface(), for distinguising classes from
interfaces. Compatibility considerations dictate that enum and annotation
types will also be represented by instances of IType.
However, there is a choice in how we add new predicates IType.isEnum() and
IType.isAnnotation() alongside the existing ones.
Option 1: Make all 4 predicates mutually exclusive.
Under this option:
class X {} // isClass; !isInterface; !isEnum; !isAnnotation
interface X {} // !isClass; isInterface; !isEnum; !isAnnotation
enum X {} // !isClass; !isInterface; isEnum; !isAnnotation
@interface X {} // !isClass; !isInterface; !isEnum; isAnnotation
Option 2: Make isEnum() a subpartition of isClass(), and isAnnotation() a
subpartition of isInterface()
class X {} // isClass; !isInterface; !isEnum; !isAnnotation
interface X {} // !isClass; isInterface; !isEnum; !isAnnotation
enum X {} // isClass; !isInterface; isEnum; !isAnnotation
@interface X {} // !isClass; isInterface; !isEnum; isAnnotation
Both approaches have their pluses and minuses.
Option 1 means that existing client code will not inadvertently deal with
the new constructs. But it may cause problems because enums and annotation
types do not fit either of the existing categories and may leave code
stumped as to what to do with something that is neither a class nor an
interface.
Option 2 means that existing clients will automatically treat enum
declarations as if they were class declarations, and annotation types as
if they were interface declarations. This is both good and bad. Good, in
that existing code will think that it's working; bad, because the existing
code will likely run roughshod over the differences and restrictions.
We'd like to hear from Java model clients about the desirablility in
practice of one option over the other.
Thanks,
jim & philippe
_______________________________________________
jdt-ui-dev mailing list
jdt-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
_______________________________________________
jdt-ui-dev mailing list
jdt-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
