On Sat, 21 Jul 2007, Frank Barknecht wrote:
It's not in my responsibility to decide, if and where people may rely
on the ouput of [unpack] and how they use it, but as I see it, [unpack
0 0] is of contract between the patch author and Pd, which states,
that this construct will always give nothing but two floats.
What is the thing that states it? The help file says that types have to be
specified, but doesn't say that type checking can be relied upon. The
source code only says what is being done right now, not what are the
intents and the expectations.
We could make abstractions that embody contracts and unit-tests, but
unless they come from Miller or are Miller-approved, this can only be a
tentative at formalising the distinction between a feature, a limitation,
an implementation detail, a bug, etc. If it's not Miller, then it has to
be some authority or some sufficiently explicit consensus. If we don't
have that, implementing a new feature is a matter of: first do it, then
try to gather complaints about it, then try to cook up some ex-post-facto
specification from it. The problem with this is that we're never safe,
there's always one more opinion that can be contrary to the reconstructed
contract and which hasn't been stated yet.
What Matju does is breaking this contract, which I can only explain by
assuming, that he doesn't view it as a contract, but views the "0 0"
part more as a kind of default value for something like [unpack
anything anything].
[unpack] does not have default values. If you unpack a list of length 2
using [unpack 0 0 0], the last outlet won't be used. The zero is never
used as a float. So, if one believes that the type declarations only have
to do with former limitations that have been overcome, the actual
arguments of [unpack] may be ignored, and instead the actual values of
them may be used.
[pack] is a rather different beast, so its case has to be considered
separately: it always outputs the same length of list, and it does use its
own arguments as defaults, but only if they are floats.
While I'm a strong subscriber to the "[t a b] and nothing else" idea
and don't use [t f] anymore, I don't think, that [t f] should ever
output a symbol,
When something is posted to the console, and it begins with "Error: ",
how do you distinguish between:
A) a mistake that the user has to fix,
B) a limitation whose existence can't be relied upon,
C) just bad luck (connection refused, out of disk space, file not found)
And/or another similar question - how do you distinguish between:
1) an error that represents a breach of contract by the user
2) an error that represents a breach of contract by the implementor
3) an error whose reporting is required by the contract
4) an error whose reporting is not specified by a contract, but which
exists by necessity
5) an error that is none of the above
6) a warning
7) a notice
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
