[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Limit looping in Grob::common_refpoint (issue 4079) (issue 134600043
From: |
Mike Solomon |
Subject: |
Re: Limit looping in Grob::common_refpoint (issue 4079) (issue 134600043 by address@hidden) |
Date: |
Tue, 9 Sep 2014 10:39:31 +0300 |
On Sep 7, 2014, at 9:46 PM, David Kastrup <address@hidden> wrote:
> Mike Solomon <address@hidden> writes:
>
>> +1. The only other solution I see is to check when the parental
>> relationship is being created, but this check results in a performance
>> hit.
>
> There is no real point in checking for a bug which one does not know how
> to recover from sensibly.
>
>> If someone cooked up a speedy algorithm, then I think it would be a
>> good idea to check at relationship-creation time.
>
> When the typical error case is that of multiple identical engravers in
> the same context, it would seem that the place to check is when adding
> engravers.
This is definitely a possibility - we’d have to set a policy that engravers
cannot be added
multiple times. I’m not sure of a case where you’d want to have multiple
instances of the
same engraver. The only thing I can imagine is someone wanting to make a custom
Scheme engraver that is added multiple times, but I’ve never seen a use case
like this.
Cheers,
MS
>
>>> https://codereview.appspot.com/134600043/
>
> --
> David Kastrup
- Re: Limit looping in Grob::common_refpoint (issue 4079) (issue 134600043 by address@hidden), k-ohara5a5a, 2014/09/07
- Re: Limit looping in Grob::common_refpoint (issue 4079) (issue 134600043 by address@hidden), eble, 2014/09/08
- Re: Limit looping in Grob::common_refpoint (issue 4079) (issue 134600043 by address@hidden), pkx166h, 2014/09/10
- Re: Limit looping in Grob::common_refpoint (issue 4079) (issue 134600043 by address@hidden), dak, 2014/09/10
- Re: Limit looping in Grob::common_refpoint (issue 4079) (issue 134600043 by address@hidden), dak, 2014/09/10
- Re: Limit looping in Grob::common_refpoint (issue 4079) (issue 134600043 by address@hidden), eble, 2014/09/10