If an execution with responsibility for an entire ‘person’ object were to try to give up its responsibility for the person's owned ‘name’ sub-object, we end up in a situation that the current system can't handle.
We could re-design Masks to allow for ‘exclusions,’ but that adds even more messy complexity to all the places we compare Masks.
Alternatively, we could expose the current design directly through the API; we could first-class masks in some way (perhaps just providing a static identifier, à la JavaScript's opaque timer-IDs? But ewwww.), and provide the actual mask acquired by requesting responsibility. If we leave no other way to create masks lib-side, and require that a mask be passed to whatever function releases responsibility … then the user can no longer remove responsibility, except in the same wholesale fashion it was acquired …
If an execution with responsibility for an entire ‘person’ object were to try to give up its responsibility for the person's owned ‘name’ sub-object, we end up in a situation that the current system can't handle.
We could re-design Masks to allow for ‘exclusions,’ but that adds even more messy complexity to all the places we compare Masks.
Alternatively, we could expose the current design directly through the API; we could first-class masks in some way (perhaps just providing a static identifier, à la JavaScript's opaque timer-IDs? But ewwww.), and provide the actual mask acquired by requesting responsibility. If we leave no other way to create masks lib-side, and require that a mask be passed to whatever function releases responsibility … then the user can no longer remove responsibility, except in the same wholesale fashion it was acquired …
I dislike both of these.