Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
obviously this is just the simplest example i was able to think of. what i was trying to illustrate is: i expect [clear, obj 0 0 foo( to clear the entire canvas and then to create an instance of [foo]. using your "delay" message for the "clear", would first create the [foo] object and then delete the entire canvas (including [foo]).
Risking to appear as an advocate for it: As I understand Tim's
no problem with that. seems like i am risking to be an advocate against it, which is not true: a warning message is better than a crash; but an intelligent handling of the problem is far better than a warning message; however, i believe that a semi-intelligent solution is worse than a warning; if this discussion helps us to make tim's proposal a fully-intelligent (sidenote: i shouldn't have started to use the word "intelligent"; now i can't find my way out...) solution, implementation schould start asap.
approach now, it could work a bit differently. The "clear" would set the "deletable" flag in every object inside the canvas, but it would not do the deletion immediatly. Then the "obj" messages could create objects, which would not have the "deletable" flag set. After the full message is executed, the flagged objects would be deleted, but the unflagged objects could remain. Which in the end would be the same as [clear, obj 0 0 foo(---[delay]---[s pd-sub]
yes this makes sense for simple assumptions. however, what about "consistent data"?
problem1: what happens if you delete a [table foo] object? what happens if you create another [table foo] instance just after deletion? this might be handled explicitely for pd's internal tables, but how about similar (external!) "tables"? problem2: how to deal with singletons? (but thinking about this reveals, that the deletion of singletons' isn't handled "correctly" anyway (actually it is not handled at all - until we have someting like the [closebang]; and once we have this, the problem will be solved anyhow); so this might not be such a big problem)
mfg.adr IOhannes