> ...maybe then there is one more thing to squeeze in then > ...or at least start the discussion so you can think about while lying > in the sun ;-)
Thanks that I am lying in the sun while thinking about your suggestion ;-) > whenever one want to get to the properties of an ArchiveEntry one has > to figure out what actual implementation it is. This kind of sucks. I fully agree. This is one of the things which usually drives me made when using such an API > Especially as there should be a limit of what you can expect/express. > After all it describes a file with it's metadata. In theory > ArchiveEntry could be the superset of all that's there. Looking at the > various implementations this doesn't seem to be too far fetched. If a > particular ArchiveEntry doesn't support e.g. getGroup() it would just > return null ...but I am a little back and forth on this. Mostly > because of methods returning primitives ...and the bloat of the > interface. ArchiveEntry.getGroup() returning null - how many different option would we implement which would return null - sometimes. What about ArchiveEntry.setOptions( Map options) and Map ArchiveEntry.getOptions? Cheers > cheers > -- > Torsten > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
