> And in fact, its very existence defies another implicit principle of
> mine, that is, the "principle of partial definition":  Defining a new
> type or instance can only break a previously typechecking program by
> making it ambiguous.  The idea behind that is that at some time you
> may realize that oen of your types already obeys another type, and
> declare that it conforms to that interface.  But you don't go the
> other way around, undeclaring that an interface holds, without your
> program having been erroneous in the first place.  Declaring that a
> new interface holds (so long as it actually does) shouldn't break
> anything that was already correct.
> The principle also has strong implications with library code:
> including a new library but doing nothing with it shouldn't start
> randomly breaking stuff.  (Unless, of course, it breaks the rules and
> does crazy stuff, in which case anything goes)

Is this better expressed as side-effect-free programming or loose
coupling/tight cohesion?


Reply via email to