[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 5362: Generalize context searches (issue 344050043 by address@
From: |
Dan Eble |
Subject: |
Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden) |
Date: |
Sun, 1 Jul 2018 14:17:12 -0400 |
> On Jul 1, 2018, at 13:14, address@hidden wrote:
>
> Something like
> origin->warning (_f ("Cannot find or create context: %s",
> ctx->identification ()))
Meh. Multiple callers would repeat the message “cannot find or create context”
which is part of what I was trying to avoid. I wouldn’t stake this whole patch
on getting it my way, but let’s mull it over while I work on the other
revisions.
If there were a good example that the message ought to be tailored to each
specific scenario, I’d more willingly let the caller provide the whole text. I
did think about that and couldn’t justify it to myself.
> Well, in this case ctx could not created, so we need an alternative
> static string Context::identification (id, name)
I like this, but doesn’t it run counter to the guidance in the CG under the
statement "Split up multi-sentence messages, whenever possible” and also “When
translating, it is preferable to put interesting information at the end of the
message rather than embedded in the middle”? Reading that, I thought that
having the context name and ID each at the end of separate messages would be
preferred.
Consider also that these proposed changes come out of an experiment with adding
a new constraint on find-context operations: properties that must be defined.
The names of those properties should be logged if the context is not found, but
they are not part of the identity. So, we could use
Context::format_search_constraints_for_logging (name, id, property_syms), or
let the callers handle the ID constraints and property constraints separately,
or keep the proposed approach of passing the source location and all
constraints into a function that does the rest.
> the
> context-identification formatter might be nice even from Scheme, with
> either a context argument or two arguments (whatever it was, symbol or
> string). That way we'd get a uniform format for such messages.
Probably worth doing separately for its own sake. Can you identify one place
you would like to see it used?
—
Dan
- Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden), dak, 2018/07/01
- Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden), dak, 2018/07/01
- Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden), nine . fierce . ballads, 2018/07/01
- Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden), nine . fierce . ballads, 2018/07/01
- Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden), dak, 2018/07/01
- Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden),
Dan Eble <=
- Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden), dak, 2018/07/01
- Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden), dak, 2018/07/01
- Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden), dak, 2018/07/02
- Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden), nine . fierce . ballads, 2018/07/02