[PD-cvs] externals/pureunity README,1.2,1.3

Wed Jan 3 01:44:30 CET 2007

Update of /cvsroot/pure-data/externals/pureunity
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28702

Modified Files:
	README 
Log Message:
some notes that I added a long time ago, plus some notes from two weeks ago.

Index: README
===================================================================
RCS file: /cvsroot/pure-data/externals/pureunity/README,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** README	13 Jan 2006 04:54:08 -0000	1.2
--- README	3 Jan 2007 00:44:28 -0000	1.3
***************
*** 403,412 ****
  > 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,
--- 403,407 ----
  > tests won't tell you this.

! [...]

  > > One limitation of documentation is that it has no enforcement power,
***************
*** 420,443 ****
  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

  +-+-+--+---+-----+--------+-------------+---------------------+
--- 415,419 ----
  that it was the contracts that acted as documentation!

! [...]

  +-+-+--+---+-----+--------+-------------+---------------------+
***************
*** 481,482 ****
--- 457,594 ----

  +-+-+--+---+-----+--------+-------------+---------------------+
+ Date: Fri, 13 Jan 2006 17:19:41 +0900
+ From: Mathieu Bouchard <matju at artengine.ca>
+ Reply-To: ruby-core at ruby-lang.org
+ To: ruby-core at 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 at artengine.ca>
+ To: pd-dev <pd-dev at 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 at 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 at 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.