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
Modify settings or unsubscribe at: 

Reply via email to