Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
On Sun, 2007-02-11 at 12:42 +0100, Frank Barknecht wrote:
What the patch is doing is deleting an object. The message causing
the
deletion was triggered by (a message that was triggered by[...])
that
object, so what? There's nothing semantically incorrect in doing that.
There is. You may be missing some implications of Pd's "depth first message passing" as described in the manual, chapter "2.3.2. depth first message passing": [1]
i wouldn't say that committing suicide is illegal, just because there is an easy explanation / workaround or the implementation of pd is buggy.
Well, then how should Pd solve the logical pitfalls in your opinion?
I'm not talking about the crash here, which of course is completly "illegal", but what would be your suggestion to what should happen, if something like this was patched:
[t b b] | | ... [s delete-the-t-b-b-above]
Should Pd just delete the trigger if a bang hits it and ignore the trigger's left outlet altogether? Or should Pd rather ignore the bang and issue a warning? The second solution would be what I would prefer, but even that has issues: What should happen to the state of the objects above the trigger:
[bng] | [f 0]x[+ 1] | [select 0] | [t b b] | | ... [s delete-the-trigger-above]
Should the counter be at 1 or should it stay at 0 if the [t b b] commits suicide and execution has to stop?
And what's with going the other way around:
[t b b] | | | [s do-something] | [s delete-the-t-b-b-above]
Should Pd first "do-something" and then, at the same logical time, delete the object that "did-something"?
To me all of this looks like a can of worms. These kinds of suicide constructs in my view are just illogical, wrong and should not be allowed. They don't do anything sensible anyway and if someone really insists on committing suicide, the right way is to insert a [delay] object as mentioned in the manual:
[t b b] | | | [delay] | | ... [s delete-the-trigger-above]
Ciao