On Sun, Aug 2, 2009 at 4:36 PM, Jody Garnett
<jody.garnett@xxxxxxxxx> wrote:
Hi Jesse:
I had a look at your changes to ID (finally!) and removed the setQualifier method - the idea is to treat an ID as immutable. I have added additional constructors to allow the qualifier to be specified during creation.
I intended to use it in an immutable fashion. My worry about adding the additional constructors is: Is the API flexible enough with the qualifier? I went the setter route because it is easier to add more properties that way. We can document them as being only usable during construction phase and even do runtime checks to ensure it. Or maybe we need a ID factory?...
Maybe that one extra field is enough. I don't know. We should decide that.
I had test failures in IDTest (since hashcode does not exactly match the toString representation anymore).
We need to clean up out test. I don't know which ones are supposed to work and on which platforms. I
I was a bit worried about the use of ID in the LayerImpl: There is a bunch of logic there (to lazily create an ID from a URL); it was not completely filling in all the ID fields (such as URI) which kind of breaks the contract. Can this logic be moved into the ID constructor for new ID( URL ) ?
This is a horrible hack just for layer becuase layer id is a URI not an ID field. So I dont really want to muddy the ID object with the hack. Layer is broken but the brokenness is hopefully restricted to the layer class.
ToString has no representation of the qualifier; could we add this to the string representation and adjust the constructors to match?
