Consider renaming emitter in EventsBase

[dshcherb]

emitter parameter name has a different meaning in EventsBase (parent, e.g. CharmBase instance) and BoundEvent (EventsBase instance).

[dshcherb]

@johnsca @jameinel

[johnsca]

Specifically in:

operator/ops/framework.py

Lines 221 to 230 in 032b274

	def __init__(self, parent=None, key=None):
	if parent is not None:
	super().__init__(parent, key)
	def __get__(self, emitter, emitter_type):
	# Same type, different instance, more data. Doing this unusual construct
	# means people can subclass just this one class to have their own 'on'.
	if emitter is None:
	return self
	return type(self)(emitter)

The emitter param to __get__ is actually the parent instance and is in fact only used to be passed into __init__ as the parent param. I vote for changing that from emitter to parent (and emitter_type to parent_type).

[johnsca]

It's also worth noting that the EventsBase instance (the on) is the actual emitter in that case, not the charm instance, but in the getter, the emitter var points to the charm instance.

[niemeyer]

The name of the emitter variable is semantic in the context of EventsBase. Every framework Object may have a parent. But this is an EventsBase, supposed to handle boilerplate for emitting events for a certain object. Which object? The emitter, which we receive via the decorator protocol on the __get__ method. As such, the fact we want an emitter as the parameter of that function is relevant, and makes the code more readable than if it was just another parent.

Looking at BoundEvent, it seems to me that the exact same is true. The emitter there is the object emitting events.

Please do raise the issue again if that's off in any way. For now, I'm tentatively closing the issue as it all seems to make sense.