some notes that I added a long time ago, plus some notes from two weeks ago.

svn path=/trunk/externals/pureunity/; revision=7131

1 files changed, 139 insertions, 27 deletions

diff --git a/README b/README
index c578038..930c0a7 100644
--- a/README
+++ b/README
@@ -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.