TODO

Prevent delete

========== async method handling? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/catch

========= • https://web.archive.org/web/20151205005155/https://blog.mozilla.org/dherman/2011/08/29/contracts-coffee/ • https://web.archive.org/web/20151002033716/http://c2.com/cgi/wiki?DesignByContract • https://en.wikipedia.org/wiki/Code_contract • https://web.archive.org/web/20150905075048/http://users.eecs.northwestern.edu/~robby/pubs/papers/ho-contracts-techreport.pdf • https://cstheory.stackexchange.com/questions/5228/relationship-between-contracts-and-dependent-typing?newreg=666f3092f1644974935c5ca8436097c4 • https://mobile.twitter.com/graydon_pub/status/1045674497271988230 • http://homepages.inf.ed.ac.uk/wadler/topics/blame.html • http://www.drdobbs.com/architecture-and-design/ada-2012-ada-with-contracts/240150569 https://web.archive.org/web/20150905075048/http://users.eecs.northwestern.edu/~robby/pubs/papers/ho-contracts-techreport.pdf

====

Contracts and variance contracts vs unit tests unit tests vs type systems

==== Are Contracts and Unit Tests dual?

==================== @demands

{Be liberal in what you accept, and conservative in what you give}

=========== https://www.eiffel.org/doc/solutions/Design_by_Contract_and_Assertions

===========

Unit testing is one thing, but a test plan is needed as well to show that the library can be installed and used in another library

================

"A class is not simply an interface. ":

Stack vs Queue interface

========

competitor/comparable https://github.com/alexreardon/tiny-invariantcompare with other contract libraries https://en.wikipedia.org/wiki/Design_by_contract

==============

Strengthening/weakening in contract subtypes:

""" The notions of “stronger” and “weaker” are formally defined from logic: P1 is said to be stronger than P2, and P2 weaker than P1, if P1 implies P2 and they are not equal. As every proposition implies True, and False implies every proposition, it is indeed legitimate to speak of True as the weakest and False as the strongest of all possible assertions. """ -- meyer p. 358

in LSP: """ Preconditions cannot be strengthened in a subtype. Postconditions cannot be weakened in a subtype. Invariants of the supertype must be preserved in a subtype. https://softwareengineering.stackexchange.com/questions/364713/liskov-principle-subclasses-can-have-stronger-invariants-how-could-it-work History constraint (the "history rule"). Objects are regarded as being modifiable only through their methods (encapsulation). Because subtypes may introduce methods that are not present in the supertype, the introduction of these methods may allow state changes in the subtype that are not permissible in the supertype. The history constraint prohibits this. It was the novel element introduced by Liskov and Wing. A violation of this constraint can be exemplified by defining a mutable point as a subtype of an immutable point. This is a violation of the history constraint, because in the history of the immutable point, the state is always the same after creation, so it cannot include the history of a mutable point in general. Fields added to the subtype may however be safely modified because they are not observable through the supertype methods. Thus, one can derive a circle with fixed center but mutable radius from immutable point without violating LSP. """ How to enforce? @invariant proxy should be able to catch this...

https://en.wikipedia.org/wiki/Liskov_substitution_principle

================ Add branching rules to Contributing.md

=============

Russian Doll Pattern vs N-version programming (page 426 of OOSC 2nd Ed.)

===================

Object-oriented Software Construction page 121 """ It is not the job of a stack module to deal with error messages, which are a user interface issue. Stack modules should deal with the efficient implementation of stack operations. To keep the body of top simple and convincing, the precondition not empty must be assumed """