On Thu, Sep 15, 2016 at 12:11 PM, Daniel van Vugt
<daniel.van.v...@canonical.com> wrote:
So actually... I now think it's OK providing the base class is named
*Observer. And only some implementations would be called *Report.
I would also be happy with this; various components take an Observer
(which provides a register-interested-party API), and Reports register
themselves as interested parties.
On 15/09/16 10:10, Daniel van Vugt wrote:
That's a good point. We don't need to change all the reporting
locations.
I still don't like the idea of having to delegate within reports, as
well as changing their construction methods.
Although I now realize my other concern that we'd have to change all
reports at once for consistency also isn't true. If a user said:
--something-report=log,lttng,...
and the SomethingReport didn't support multiple implementations yet
then
that's just a syntax error.
I guess my remaining concern that's unresolved is the existing
assumption that reports don't affect the control flow of the server.
But
that's really just a naming issue -- if it was called
SomethingObserver
then it would be OK. Just the word "report" makes me think it is
ineffectual to server behavior.
On 15/09/16 10:01, Christopher James Halse Rogers wrote:
On Thu, Sep 15, 2016 at 11:57 AM, Daniel van Vugt
<daniel.van.v...@canonical.com> wrote:
Not impossible, but it feels too ugly. I would prefer to keep
reports
for debugging/logging only where they don't affect the behavior of
the
server. And programmers can assume this is true without knowing the
implementation details of any given subsystem.
I agree, but
The implementation is potentially also ugly. At each point where a
report happens you can't any more say:
report_interface->report_something()
because that would only call one implementation. So we would need
to
change the architecture of all reports and for consistency change
them
all. It doesn't sound nice.
...this wouldn't actually be true? We'd just make
the_report_interface()
not an override point and instead always have the same
implementation
(which would then delegate to whichever report implementations have
been
registered).
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
