[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adds outside-staff-interface and outside-staff-axis-group-interface
|
From: |
dak |
|
Subject: |
Re: Adds outside-staff-interface and outside-staff-axis-group-interface (issue 37950044) |
|
Date: |
Mon, 16 Dec 2013 10:07:34 +0000 |
On 2013/12/16 09:58:40, mike7 wrote:
On Dec 16, 2013, at 11:45 AM, mailto:address@hidden wrote:
> The summary seems incompatible with
> <URL:http://music.stackexchange.com/a/14160/8773>
>
> Once an interface is required for outside-staffing a grob, the set
of
> grobs one can use in that manner is hardwired to the "intended"
grobs.
This is true. The outside-staff-interface would need to be applied to
every
grob that could, in theory, be shifted this way. I’d need help in
flagging
grobs I’ve missed - I’ve gotten everything that uses it in the
regtests, but
there are others that are not tested. The stackexchange example is
one of
them.
I think the hardwiring is good in that we should avoid letting grobs
implement
interfaces with properties that could never, in any circumstance,
apply to them.
[...]
As a corollary, if it doesn’t exist already, we may want to create a
mechanism
to add or subtract interfaces from grobs at runtime.
As a corollary, if it doesn't exist already, we may want to create a
mechanism to add interfaces to grobs with properties that could never,
in any circumstance, apply to them?
That does not look like a corollary. More like an antithesis.
https://codereview.appspot.com/37950044/