On 2016/08/02 11:27:22, dak wrote:
Personally, I think that this "remove-layer is either a layer number
for
ourselves or a list of supportive layer numbers who can keep us alive
unless
this list is empty in which case we can be kept alive by our own keep-alive-events" is just a bit too much meaning crammed into one
property.
I've taken a look a
Sorry, wrong key. I've taken a look at the code and it does not appear like there is a danger for infinite loops: the checks for suicide relying on other axis groups are not called recursively. The only real danger we are dealing with here is inefficiency, and particularly undefined behavior since a context may decide to commit suicide based on the status of a context which already suicided on the expectation of the first context staying alive. If the order of checks in such a situation are reversed, the outcome may be different. Should we declare this "somebody else's problem"? At the low level, dependencies are decided by make-dead-when and keep-alive-with properties (containing vertical axis groups) which are populated based on the remove-layer setting. If we want to provide the underlying flexibility, we'd likely need a remove-layer property and _two_ properties carrying lists of layer numbers. Or _one_ property with a list where the _sign_ of the layers indicates friend or foe. However, using the sign will _fix_ layer numbers to be numbers. When going general like that, going via key-list? seems plausible, and then we'll require two additional lists anyway since a symbol cannot provide a sign. So would it make sense to provide the full hog that the low-level decision engine supports? Basically, we want the kind of user interface where people need to think the least but still can do everything they want to. https://codereview.appspot.com/308910043/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
