Re: Adding an interface to provide a list of listeners

On Sun, Jul 27, 2014 at 7:27 AM, Anne van Kesteren <[email protected]> wrote:

> On Fri, Jul 18, 2014 at 12:51 AM, Karl Groves <[email protected]>
> wrote:
> > I'm not sure the reply "this been discussed and rejected several times
> > before ... I would advise against reopening the discussion."  is terribly
> > helpful. To Shane's original question: which WG would be best to address
> > this with or to search down the history of the relevant discussions? Is
> > there a way to get access to those previous discussions or at least a
> > summary as to why?
>
> This list would be the best place for such research.
>
>
> > And that search turns up almost a quarter-of-a-million results. The top
> > results are quite relevant to this discussion and also demonstrate that
> many
> > people are looking for such a thing.  The fact is, the browsers
> themselves
> > already have this, but it isn't exposed in a way that devs can get to.
>
> The reasoning is that listeners are observers and adding one should
> not have side effects. Exposing listeners leads to abuse.
>

Both the action of adding a listener (observer) and invoking a listener can
and does have side effects. So I don't see why you say it should not, since
it clearly does.

Furthermore, exposing the existence of listeners doesn't itself produce a
side effect, though if such exposure also leads to invocation of the
listener's call back, then it certainly might.

I wonder what the 'abuse' might be. Can you be more explicit? I can imagine
that if an add-on enumerates all listeners and by doing so discovers all
non-add-on added listeners, it could then remove or augment (e.g., replace
the listener with its own that does something else and then invokes the
original listener).



>
>
> --
> http://annevankesteren.nl/
>
>