Hi Bryan, Bryan Atsatt wrote:
... By having Dependency extend Query, instances can be directly passed to Repository.find(); no conversion required. We could obviously just make a getter for the Query if we want, but why not make this convenient to use?
An import dependency describes the relationship between two modules. It is true that we may want to query a module described in the import dependency, but an import dependency itself is not a query. In fact, someone may even want to query a module which contains the specific import dependency, although I think this use case is very rare. Anyway, it sounded like the main benefit to have import dependency extend query is to make it easier to pass into Repository.find(). Unfortunately, once a class is extended from another, all the public/protected methods/fields from the parent class would automatically become part of the signature of the child class. I don't think we want to pollute the class hierarchy and potentially confuse developers just for a bit of convenient. ;-)
Second, I think we should eliminate VersionConstraint as a separate class. It's functionality is easy to replace with Query elements that match Version or VersionRange, strung together with appropriate boolean operators.
There are methods in VersionConstraint for determining if it contains a specified version/version range/version constraint. These methods are used heavily for version constraint override in module initialization/import policy/import override policy, and they are not suitable to be moved into the Query class. I think VersionConstraint should stay as a separate class.
Third, we should add a getExportedPackages() method to ModuleDefinition. This way a Query can easily be created to search by package name. Whether or not we choose to surface import-by-package declaratively, it should at least be possible for a ModuleSystem to use such a Query.
Having something like getExportedPackages() sounds reasonable from the perspective of interoperability.
Fourth, we should add support for simple attribute constraint declarations. Enabling simple equality constraints ought to be easy enough: an AttributeConstraint annotation that takes key/value lists (key1==value1;key2==value2;...). We already have support for expressing these as Query instances.
The Query class currently only supports querying arbitrary attributes at the module level. Are you suggesting that we should let developers to declare arbitrary attributes at the import? Could you come up with real use cases for this in the context of 277 alone?
Finally, Query ought to have a toString() implementation so that we can log them, examine in a debugger, put them in error messages, etc.
The Query.toString() will output a human readable string, and this is already implemented in the RI. - Stanley
