On Nov 29, 2007 10:57 AM, Rob Heittman <[EMAIL PROTECTED]> wrote:
> Hmmm. I feel myself spiraling back to the interfaces vs classes question.
Don't go into the light! :-) Isn't this just more evidence that it's very
hard to specify interfaces in unstable APIs?
But now you've got me thinking. What if (some day) there were a suite of
small interfaces like this:
interface AcceptsRepresentations<T> {
AcceptResult accept(Representation<T> rep);
}
and resource (lower-case 'r') classes just implemented these interfaces, e.g
.,
class MyResource
extends AbstractResource
implements AcceptsRepresentations<SomeRep>, GetsRepresentations,
RemovesRepresentations {
public AcceptResult accept(Representation<SomeRep> rep) { ... }
// get/variants, remove, etc.
...
}
That would finesse the whole exception issue, since the AcceptResult (and
other XXXResult types) would carry the information that an exception would.
> Other than imposing a consistent method naming scheme
> (checkedStoreRepresentation is the checked version of storeRepresentation
> ...) your proposal would work for me. I would want the ability to do a
> fairly simple regex operation across my code in the future to remove the
> extra level of wrapping.
>
These names should typically only appear in method declarations of
CheckedResource subclasses, so it should be easy to change them. And
wouldn't you prefer shorter, less redundant names, e.g.,
accepts(Representation) instead of acceptsRepresentation(Representation)?
--tim
