diff options
Diffstat (limited to 'README')
| -rw-r--r-- | README | 166 |
1 files changed, 139 insertions, 27 deletions
@@ -1,4 +1,4 @@ -$Id: README,v 1.2 2006-01-13 04:54:08 matju Exp $ +$Id: README,v 1.3 2007-01-03 00:44:28 matju Exp $ PureUnity @@ -402,12 +402,7 @@ you can refactor those tests like this: > (say) Complex vectors or BigDecimal vectors is intended or not. The unit > tests won't tell you this. -I once called unit-tests "test-by-example" and contracts "test-by-rule". I -think that those names are preferable to the more common names. I also had -listed "test-by-use" which is to use the software in practice: this may -include testing a component A using the unit tests for B because B uses A. -The last I had listed was "test-by-proof", which is rarer and is the only -one that requires analysing the implementation. +[...] > > One limitation of documentation is that it has no enforcement power, > > so you have to write tests anyway to test conformance. @@ -419,26 +414,7 @@ That was a pretty bad case of strawman argument. Dean was assuming that your documentation was not executable when you had quite clearly stated that it was the contracts that acted as documentation! -I've thought of a triad: - - A. "the real thing" - B. what it's documented as - C. a way to verify that (1) and (2) agree - -and another one: - - changing A to match B+C: - programming - - changing B to match A+C: - the scientific method (aka reverse engineering) - - changing C to match A+B: - unit-tests and contracts and scientific experiments - - _ _ __ ___ _____ ________ _____________ _____________________ ... -| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju -| Freelance Digital Arts Engineer, Montréal QC Canada +[...] +-+-+--+---+-----+--------+-------------+---------------------+ @@ -480,3 +456,139 @@ Unit-tests vs contracts is a false debate. +-+-+--+---+-----+--------+-------------+---------------------+ +Date: Fri, 13 Jan 2006 17:19:41 +0900 +From: Mathieu Bouchard <matju@artengine.ca> +Reply-To: ruby-core@ruby-lang.org +To: ruby-core@ruby-lang.org +Subject: Re: Design contracts and refactoring (was Re: mathn: ugly warnings) + +[...] + +In order to entrench the tests-as-documentation habit firmly in the Ruby +community, we need a catchy acronym. Like RTFUT = Read the Fabulous Unit +Tests! + ++-+-+--+---+-----+--------+-------------+---------------------+ +http://lists.puredata.info/pipermail/pd-dev/2006-01/005920.html +Date: Fri, 20 Jan 2006 23:52:22 -0500 (EST) +From: Mathieu Bouchard <matju@artengine.ca> +To: pd-dev <pd-dev@iem.at> +Subject: macros and such (was: pd-lib, SIMD) + +[...] + +I think that the Pd source doesn't use nearly enough macros or other +code-reducing tricks. + +The reduction of code isn't so much about making things use less RAM: the +RAM excuse is quickly evaporating as even the tiniest computers come with +plenty of RAM and even the faster kinds of RAM come in ever more copious +amounts (big caches). + +The reduction of code is programmer-oriented. I'm not talking about length +of identifiers here (this is a separate issue). Every line of code should +do something interesting by itself. Code should read like a good story and +not like a car. Ever tried to read a car? It's boring. The same damn +piston copy-pasted 12 times. + +The reduction of code is also documentation-oriented. Once the programmer +has been contaminated with the wisdom required to make small code or +understand small code, then why wouldn't the programmer explain it to his +students in higher-level terms instead of chanting 12 times the same +piston as if it were a marathon of Hail-Marys ? + +This is why Pd needs a taxonomy of object classes. If I don't get that +taxonomy in Pd itself nor in its help files, at least I'll have it in its +unit tests. + +Once and only once. +Once and only once. +Once and only once. +Three strikes and you refactor. +for x in [1,2,3] say: Once and only once + +http://c2.com/cgi/wiki/?ThreeStrikesAndYouRefactor + +BTW I'm not talking about only inheritance of implementations. The most +important thing to me is inheritance of expectations, so that if I name +100 classes that obey the rule "Operator2", then you have just learned +something common about 100 classes. + +Operator2 means right-inlet is cold, left-inlet is hot, there is a "set" +method for using left-inlet as cold, there is a "bang" for explicitly +activating the main computation. The main computation only produces one +message. That's what "Operator2" means in my taxonomy, and it's that much +that hasn't to be stated explicitly in each help patch. + +Help patches can be abstractions to be used to by other help patches. Just +put a [operator2-help] object in your help patch to indicate that the +currently documented class obeys the standard operator2 rules. + +Who's against it? + ++-+-+--+---+-----+--------+-------------+---------------------+ +http://lists.puredata.info/pipermail/pd-list/2006-02/035169.html +Date: Sat Feb 4 21:22:29 CET 2006 +From: Mathieu Bouchard <matju@artengine.ca> +To: pd-list + + * Previous message: [PD] dealing with arguments and inlets + * Next message: [PD] Re: [PD-announce] A new version of FFTease is now available for Pd + * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] + +On Fri, 3 Feb 2006, Hans-Christoph Steiner wrote: + +> The way I have been thinking is that the first inlet is the general +> inlet, and it can accept many types of messages. Then the second inlet +> lines up with the first argument, the third inlet to the second +> argument, etc. + +I agree. Many objects obey the rule that the k'th inlet matches argument +$k for several arguments in a row, usually all of them. + +> I think this is pretty clean and flexible, and I think +> it would be nice to have some kind of standard for this. + +And the best way to make sure people are following a standard is to make +it so easy to follow that it's harder to not follow it than to follow it. +Of course I don't mean adding hurdles to doing it otherwise, but rather +make a shortcut for those who follow the standard. Short of this, people +who make abstractions/externals can get a friendly reminder, from someone +who cares, that it would be better if they followed the standard. + +> Obviously, it doesn't work for all objects, but I think it would be good to +> standardize on objects it does work for. + +PureUnity's goal (when I work on it) is to design a taxonomy that +separates objects that obey certain properties, from those that don't, +because that's a way to reuse tests, but also because certainly it doesn't +hurt documentation either, and it's even better if it can influence how +abstractions are made. + + _ _ __ ___ _____ ________ _____________ _____________________ ... +| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju +| Freelance Digital Arts Engineer, Montréal QC Canada + ++-+-+--+---+-----+--------+-------------+---------------------+ +From matju@artengine.ca on Dec 18, 2006 + +I thought up some kind of classification of type systems, avoiding to call +them strong/weak or static/dynamic because those words are confusing. + +1. Typed expressions: each piece of code that can give a value, has a +type that can be figured out at compile-time. + +2. Typed variables/parameters: declarations allow runtime checks but not +compile-time checks. + +3. Typed values: variables don't have types, they can contain any value, +but every value has a type. + +4. Typed uses: values don't have types, a type is a way of using a value. + +Strictness, in the sense of forbidding things to the user, is not on that +scale, it's another aspect. A well-balanced strictness allows one to +bypass the system whenever needed, but without being too error-prone. + +However it's difficult to say what it means to "bypass the system" for all +four typing categories at once, or even within one category. |