Sounds good to me. I wouldn't actually throw out any methods, simply
because eventually someone will have to put it back in and that's just
more time -- there's usually also a good reason a method hook has been
put in, I imagine. I can see the situation where someone would be
implementing something, find they need to support an optional method
somewhere else and put an empty hook in. I just really needs to be the
policy to have these hooks as throwing Errors rather than simply sending
back nulls (which in a lot of cases is a valid result -- so the calling
code expects it and takes an appropriate codepath, not knowing that the
actual result is an error). I'm more for an Error throw rather than an
Exception, simply because bad calling code may just swallow exceptions.
I don't think any of it will expect NotImplemented, and we need
something that will unavoidably spit out the result of calling a dead
method. I may be barking up the wrong tree here -- if NotImplemented
allows this behaviour by descending from an appropriate superclass, then
by all means use this. But I think the very thing we want to avoid is
silent handling of these hooks, whether it be by null or an exception
being swallowed by catch (Exception e) {} (and yes people do this...).