Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
Hm, is this "specified" somewhere? Or is it just "the way it is" currently, similar to the way, two connections of a message outlet are currently handled by creation order, however by specification the order there is undefined?
are you referring to a language specification ;-)
Somehow yes. But Miller clarified this point for me.
My practical view to loadbang ordering is simple: The only elegant way to solve the problem is triggers. They make the ordering explicit and printable.
well, this only works as long as you are the maker of all loadbangs. when you start to distribute a collection of abstractions (don't you ;-), you can't be sure any more that your user's loadbang occurs after your loadbang. basically ANY abstraction that should be reusable by others can't use loadbangs/loadbang-based externals.
More correctly it would be like this: others can't use loadbangs/loadbang-based externals that rely on being activated in a specific order.
I see, that it is useful, that abstractions are loadbanged before their parents. However I really don't know a simple and practical solution to the case where you'd want to have one abstraction bang before another, maybe even an instance of the same abstraction, in a case, where they are on the same hierarchical level
Or rather, somehow it feels wrong to me to have to rely on a kind of automatic ordering of loadbangs in abstractions/subpatches which are on the same hierarchical level. This is something I would rather let the user of these abstractions to ... probably using triggers. ;)
The good thing is: A loadbang only happens once.
Ciao