Dan Eble <d...@faithful.be> writes:
> On Jul 1, 2018, at 15:08, d...@gnu.org wrote:
>>
>> We currently have
>>
>> dak@lola:/usr/local/tmp/lilypond$ git grep "find or create" lily
>> lily/context.cc: warning (_f ("cannot find or create new `%s'",
>> lily/context.cc: warning (_f ("cannot find or create `%s' called `%s'",
>> dak@lola:/usr/local/tmp/lilypond$
>>
>> That's not multiple callers. It's two different messages for two
>> different situations. Why would a sensible refactoring introduce more
>> callers?
>>
>
> The current code has the messages built into the search methods, so
> there are only two. My patch pulls them out, letting the callers
> decide whether to warn, and there are six callers that choose to warn.
>
> change-iterator.cc: Context::warning_cannot_find (origin, to_type,
> to_id);
> context-specced-music-iterator.cc: Context::warning_cannot_create
> (origin, ct, c_id);
> context-specced-music-iterator.cc:
> Context::warning_cannot_find_or_create (origin, ct, c_id);
> context.cc: Context::warning_cannot_find_or_create (/*source
> location*/ 0, name, id);
> quote-iterator.cc: Context::warning_cannot_find_or_create (origin,
> name, c_id);
> simultaneous-music-iterator.cc: Context::warning_cannot_find_or_create
> (get_music ()->origin (),
>
> It might make sense for the one in context.cc to be pulled out into
> its callers as well, but I was not planning to investigate that now.
So what benefit do we get from forking out two different warnings for
two different situations into one warning for six situations? What does
your code do better after the refactoring making this desirable?
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
