That's an interesting question and I'd be interested to read more =
opinions on this.

What I've done in the past, is to add the required methods to the module =
itself. For example, in your case you could add

def birthdate
  raise 'base classes should redefine this method'
end

to your module.

I think the general disdain against strictly type-based enforcements =
stems from the fact that Ruby is extremely dynamic; by restricting =
behaviour to certain types you're making it harder (not impossible) to =
extend the behaviour or to use it in new or novel ways.


On Dec 11, 2011, at 9:45 PM, Grary Stimon wrote:

> OK, right.
>=20
> I still can't get the test result I expect in this case...
>=20
> But as a general matter, I have noted the general disdain Rubyists =
have
> for abstract class-like enforcement mechanisms. And it's true that if =
I
> want to rule out runtime errors by enforcing the presence of certain
> parent class methods in any implementing children, then I've got to =
put
> all this stuff in the parent to ensure that, as I have been trying to =
do
> with the Module hooks.
>=20
> ALTERNATIVE APPROACH -- which I take to be more Ruby -- is to trust =
the
> implementer to follow the documentation for the parent -- taking
> responsibility for runtime error stuff, themselves. I might try to =
help
> them by adding test examples that they can take from my parent module
> and run against their child implementations.
>=20
> Is my alternative approach the way to go, or do good Rubyists enforce
> parent module contracts to avoid runtime errors in the implementing=20
> children?
>=20
> Grar
>=20
> --=20
> Posted via http://www.ruby-forum.com/.
>=20