Re: class contract proposal finished

Mark Hahn wrote:

> http://prothon.org/wiki?pagename=DesignByContractClass
> 
> This works pretty much the same way as the properties proposal.  It lets the
> interpreter do all the work.

Fundamentally I've never understood the problem you are trying to solve 
here. I've heard of Design By Contract but I don't understand what your 
proposal has to do with it. I've always thought of Design By Contract as 
being about Eiffel-style preconditions and postconditions.

http://www.google.com/search?hl=en&lr=&ie=UTF-8&safe=off&q=design+by+contract+python&btnG=Search

It has pretty little to do with a bunch of static-style rules on 
assigning to properties of objects etc.

Designing features to allow large-scale software engineering is 
difficult and I don't think it is something you do off the top of your 
head. You need an articulated theory about how large-scale engineering 
works and why traditional languages fall short. Then you design the 
features to fix the problems. But your DBC has no rationale about why 
specific restrictions would realistically make it easier to build large 
programs.

If you go back to Eiffel, you'll see that in their minds it is basically 
about a) runtime testing and b) static declarations. Unit testing is 
also promoted by modern "agile programming" methodologies. They are 
probably complimentary mechanisms and could work together. A language 
could add explicit support for both to make it easier.

  Paul Prescod