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@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.