ImportDependency

[Stanley M. Ho]

These are reasonable suggestions. According to the code conventions, 
class names should be nouns:

http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html

As Adrian and Bryan suggested, I will remove the getType() method from 
ImportDependency. A module system may need to recognize dependencies in 
a module definition from other module system for interoperability (e.g. 
recognizes module re-export), so I think we will need to define common 
dependency types like ModuleDependency and PackageDependency in the API.

Regarding whether we should use interfaces vs abstract classes, Joe 
Darcy has a very good write-up on this topic recently:

http://blogs.sun.com/darcy/entry/api_design_interfaces_versus_abstract

Since these import dependency types are created and used mostly by the 
module systems and each module system may have its own set of 
implementation for these types, defining them as interfaces is probably 
a more sensible thing to do. I will also move the factory methods from 
ImportDependency into Modules for now.

I will make these changes in the next revision of the draft API 
specification. Let me know if there are other feedbacks on this.

- Stanley


Adrian Brock wrote:
> I agree, getType() looks wrong to me
> (not very object orientated ;-)
> 
> But I'm not sure that the spec should define import module and package
> as explicit subclasses or that Import[Dependency] should be a 
> concrete class?
> 
> I'd prefer to see interfaces. The factory methods would
> just construct implementations of those interfaces.
> 
> Somebody else would be free to implement them in a different way,
> e.g. as a wrapper/adapter to the equivalent manifest information of a
> 291 implementation.
> 
> On Wed, 2008-06-11 at 13:11 -0700, Bryan Atsatt wrote:
>> The design of this class seems broken to me with the addition of two 
>> "types". Why not:
>>
>> 1. Make ImportDependency abstract, removing the getType() and newX methods.
>> 2. Make ImportPackage and ImportModule subclasses, each with their own 
>> newX method.
>>
>> (I also strongly suggest that we rename ImportDependency to simply 
>> "Import" :^)
>>
>> This model also obviously enables new subtypes, an extensibility point 
>> that may come in handy in the future.
>>
>> // Bryan