feedback (not a bug): Terminology confusion with "listeners"

[GoogleCodeExporter]

This is probably not the most appropriate forum, but I don't see any lists
or other way to offer feedback.  Maybe a wiki page, but outsiders can't
actually create pages. Anyway...

The use of "event" and "listener" is kind of confusing, especially when
you've built it on an event-oriented framework already.  It also sort of
jangles with common sense, the idea that a staff can simply "listen with
goblin chief logic".  I think the reason for the dissonance is only the
terminology.  At first glance, what I'm seeing is that you have a
delegating object model, wherein objects receive _messages_ that they
dispatch to _delegates_ (as opposed to methods they resolve up their class
hierarchy).  

Now it's true that a lot of systems based on delegation in fact use it as
their inheritance model (Self comes to mind) but it isn't a totally
necessary condition (the Io language has both inheritance and delegation).

I think the delegation model is well suited for a MUD, and you've got a
nice sound model that other codebases really lacked.  That I'm only
quibbling about terminology is probably a good sign :)

Original issue reported on code.google.com by cja...@gmail.com on 1 Mar 2007 at 7:51

[GoogleCodeExporter]

I think you have a very valid point here; I also dislike confusing and vague
terminology. The terms I'm currently using are just the ones which occurred to 
me as
I was writing the very first versions of the code: 'listener' is so called 
because it
'listens' to an object's 'events' (in Self terminology, then, that becomes a
'delegate' that is delegated 'messages'?)

One thing I'm slightly uncomfortable about with this set of terminology is that
'message' already has a definition in OOP, which isn't incredibly close to how I
think of listeners/delegates behaving. Also, 'delegation' seems to refer to the 
case
of one object explicitly handing off control to another in its own code: my 
model
seems closer to the observer pattern.

I wouldn't be unhappy with a renaming of 'listeners' to 'delegates', however: 
it is a
more descriptive name, and does carry a sense of activity, rather than the
passive-sounding 'listener'. As for renaming 'events' to 'messages', I think it
retains the same problem of already having a meaning (Twisted actually 
more-or-less
equates events to OOP's traditional messages, further confusing the situation).

On the topic of this being the right forum for terminology discussions: I can't 
think
of a better one than an issue tracker. And thanks for the feedback, it is 
appreciated
- I'll see how 'delegate' sounds and feels when it's used in the code.

Original comment by free.con...@gmail.com on 1 Mar 2007 at 10:05

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by free.con...@gmail.com on 2 Mar 2007 at 5:37

• Changed state: Accepted

[GoogleCodeExporter]

It's true that some OOP systems like Smalltalk already have some meaning 
attached to
'message', but it's pretty well absent as a technical term in python (which 
prefers
'method'), so I wouldn't see anyone getting confused over it -- certainly less
confusion than 'event'.  Basically, a message is a request to invoke a method,
somehow.  This as opposed to methods in python where you resolve the method as a
value first, then directly invoke it (you can always use proxies and 
__getattr__ to
do messages, but that's not the out-of-the-box object model).  

On the surface, the binding's a little looser than smalltalk, where you always 
send a
message to an object, but smalltalk systems often [ab]use metaclasses and/or
#doesNotUnderstand to achieve much the same effect anyway.  So I wouldn't worry 
too
much about the name collision :)

Original comment by cja...@gmail.com on 2 Mar 2007 at 9:53

[GoogleCodeExporter]

So, after much procrastination, listeners have been renamed to delegates, 
having come
to the conclusion that it is indeed a much better name. About events -> 
messages: I'm
not wholly sure that this one is worth it for the effort involved (sed sounds 
lovely
and simple in manuals, but cmd.exe is a horrible abomination).

But, this might change depending on circumstance (eg, if I get a proper shell), 
so
I'm not going to close the issue right now. Further rumination is be needed.

Original comment by free.con...@gmail.com on 10 Mar 2007 at 9:48

• Changed state: Started