[
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
|
Hi Mik, Thanks for the suggestion. We use typesafe enums in the DOM/AST
API, but not in the older Java model API. Maybe its a good time to start.
Besides IType.isClass/isInterface, there is also IType.getFlags() which
returns modifier flags also capable of expressing the distinctions between
classes, interfaces (AccInterface), enums (AccEnum), and annotation types
(AccAnnotation). So we've got the based covered seven ways to Sunday <g>.
---jim
"Mik Kersten" <beatmik@xxxxxxxxx>
Sent by: jdt-ui-dev-admin@xxxxxxxxxxx
03/12/2004 12:22 AM
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
Just joined the list--apologies if I've missed relevant past discussion.
I'm a committer on the AspectJ and AJDT projects.
Instead of adding more "is<mumble>()" methods, you could also consider
using
a typesafe enum (Bloch) for distinguishing the different kinds of IType.
This could be a win if more kinds of ITypes surface down the road (I have
aspects in mind). It can also simplify the code patterns, eg:
switch (type.getKind()) {
case IType.CLASS: ...
case IType.INTERFACE: ...
case IType.ENUM: ...
case IType.ANNOTATION: ...
}
and common operations could be captured, e.g. a test for "isClass() ||
isEnum()" could be captured by a method on IType.Kind:
if (type.getKind().hasMethodImplementations())
The IType.isClass() and IType.isInterface() methods could be left for
compatibility (perhaps deprecated). Note that this is orthogonal to the
predicate options, and I too would prefer to see this or the
"is<mumble>()"
methods work with option 1.
The thing that I'm usually after is extensibility in the model. For
AspectJ
the kind enum might be a moot point since we need an IAspect subtype of
IType anyway (we have additional kinds of members). So ideally for us the
differences in type kinds would have been captured by the element
hierarchy.
Making them more explicit in an enum could help some--if the enum pattern
is
used, not the 1.5 enum, then we will be able to extend IType.Kind with
additional kinds in our subtype.
Mik
--
http://kerstens.org/mik
> -----Original Message-----
> From: jdt-ui-dev-admin@xxxxxxxxxxx [mailto:jdt-ui-dev-admin@xxxxxxxxxxx]
> On Behalf Of Mike Wilson
> Sent: Thursday, March 11, 2004 6:37 AM
> To: jdt-ui-dev@xxxxxxxxxxx
> Cc: jdt-ui-dev@xxxxxxxxxxx; jdt-ui-dev-admin@xxxxxxxxxxx; Philippe P
Mulet
> Subject: 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
>
>
> _______________________________________________
> 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
