Reports as system-state Observers

[Daniel van Vugt]

Sure, renaming things isn't ever absolutely necessary. However the more 
accurate naming of the interface being an "Observer" if some additional 
implementations are to be non-reports, feels much cleaner. So we should 
at least rename the one in question. Not all of them at once...

And if a method is named "report_foo" then it would also need renaming 
to something like "on_foo".


On 16/09/16 14:51, Alan Griffiths 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.vugt at 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.
>
> With regard to Chris's MP - I don't believe we want both a "Report" and
> an "Observer" both doing the same job as a solution to /4/.
>
>