[quote user="Paul Connelly"]The order of updates to a single element is indeterminate and should also be irrelevant.[/quote]
How can you be really sure? Say the shape is generated by Bentley's GenerativeComponents, and has one of its vertices dimensioned using Mstn's associative dimension tool.... and John's area reporting tool. Surely, the Dependency Manager will need to step in and prioritise the dependencies... before handing back to the display system or whatever. The GC team would have the advantage of talking to the platform team and peek at each other's source code but this would be a problem for ISD's and users. I would have thought that there should be some more proactive dependency management.
[quote user="Paul Connelly"]Propagation will abort after max recursion exceeded, which usually implies an infinite loop.[/quote]
Is that what that means? I see this message sometimes in Mstn and ABD. Seems like bad coding practice... if you have to wait for the apps to abort to find out that you have a bug in the code. This will be impossible in the wild, when you would not know which apps would be active. It must also make Bentleys life tougher if you need to cobble together 'companion' verticals like ABD and GC; ABD and Descartes or LumenRT, debugging -wise.
[quote user="Paul Connelly"]I see no issue with the scenario you describe wherein a constraint determines the shape's area, and the shape's area determines the contents of Jon's field.[/quote]
Yes, it is a short and simple dependency... and all the data is 'private' and managed / duplicated by each separate app. Unfortunately, that is not always possible or desirable in the real world.