On Tue, 6 May 2003, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Wish
- [inlet] and [outlet] should have numeric argument.
Because...? It would break a lot of patches, I guess.
No, obviously, backward compatibility can be kept by omitting the argument; I mean, the way I propose does not conflict with the current way.
The position is saved in the patch file and thus can be deduced from reading the patch file (y-coordinate). In this regard it is not purely graphical.
Well duh, it's saved in the patch file. It _has_ to be saved in the patch file, else the users would be mad. But I call it graphical anyway. (How would _you_ call it, then ?)
For example, if several connections come out of an outlet, connections are treated in an unspecified order.
You're right, that this is a bit confusing.
I am not saying that this is confusing, I am saying that this is an example of unspecified behaviour. I didn't say that unspecified behaviours are confusing either. I did mean that some things are meant to be naturally left unspecified, and that in that case, another means should be there to allow one to control the behaviour explicitly. In this example, there is [t] (which you mentioned), although it is a kludge (see my mail about [t a a] messing with some messages' contents)
Well, to rely on "unspecified order" isn't a bug, it's stupid.
A "bug" is not necessarily something that doesn't work *now*. I know a lot of bugs (bug types) that only occur once in a while randomly. Well, they still are bugs. Relying on unspecified behaviour is, to me, a bug.
- Each functionality must be accessible by at least one explicitly
specified behaviour. (i.e. unspecified behaviours do not count as a valid way to use a feature)
See [trigger] again. Or maybe I missed the whole point?
You missed the whole point. This example was only used to illustrate the rationale behind my solution to the issue with [inlet]/[outlet]. The numeric argument thereof (specifying inlet/outlet number) would be to the [inlet]/[outlet] problem what [t] is to the connection-ordering problem.
Mathieu Bouchard http://artengine.ca/matju