On Fri, Sep 16, 2016 at 5:08 PM, Christopher James Halse Rogers
<ch...@cooperteam.net> wrote:
On Fri, Sep 16, 2016 at 4:51 PM, Alan Griffiths
<alan.griffi...@canonical.com> wrote:
On 16/09/16 02:51, Christopher James Halse Rogers wrote:
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.
1. the user of the "Report" interface is the core code - which is
simply reporting something. The code reads "report->xxx()" which is
clear.
2. we've had this name for years, without considering it a problem.
3. Some implementations of "Report" log, some don't - which is the
behaviour that was originally intended (and what we all want).
4. I *think* the current issue is simply that we want to add support
for multiple reports/observers so that code using Mir can get
notifications without disabling the supplied logging/lttng options.
We have existing generic "observer" code that can be used to
composite reports.
In short, I agree that "Reports" are taking the "Observer" role from
the pattern language, but I think the more specific name is good
here and I don't follow why folks want the pain of a rename.
So, I think what's happening here is:
For some subset (including me) of the Mir team, the term “Report”
has a bunch of implicit semantics, including
*) This is optional, for post-hoc human-based debugging only
*) This is *purely* observational; it might log in any number of
ways, but the *only* state it's going to change is the state of some
logging system.
*) The calls are approximately equal to printf; relatively cheap and
simple.
Which is why (1) and (2) are problematic - we *do* think that the
meaning of report->xxx() is clear, and isn't a problem, but we think
it means something significantly different to what you do.
Also - this is why the pain of a rename might be appropriate. At least
some of our code that calls reports will *break* if it's used to drive
code. Because we've not considered reports to be arbitrary callbacks,
we do things like call them while holding locks that will cause
deadlocks if code calls back into the object.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
