Events vs. EventManager

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Events vs. EventManager

Andreas Möller
Hello list,


may I ask why instances of EventManager are referred to as events, rather than eventManager?


Best regards,

Andreas
--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

Artur Bodera
On Tue, Nov 13, 2012 at 10:38 AM, Andreas Möller <[hidden email]> wrote:

> Hello list,
> may I ask why instances of EventManager are referred to as events, rather
> than eventManager?
>

Reference please.

In general, "events" is just a shorthand. It is used througout
communication to reference either EM, Event object (or its subclass, i.e.
"mvc event"), event type name (i.e. "dispatch events") or the fact of
triggering an event.

It might be hectic in some places in the manual, however I am unable to
determine if it's messed up enough to be confusing for beginners. Better
ask some genuine beginner about that....

--
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

Andreas Möller
Hello Artur,


> Reference please.

Search for

* $events
* protected $events

in clones of

* git://github.com/zendframework/zf2-documentation.git
* git://github.com/zendframework/zf2.git

> In general, "events" is just a shorthand. It is used througout communication to reference either EM, Event object (or its subclass, i.e. "mvc event"), event type name (i.e. "dispatch events") or the fact of triggering an event.  

Exactly!

And that's the point - most occurrences refer to instances of EventManager, rather than - what one would expect from the naming - a collection of events, an array of events, etc. To make it more clear what it *really* is, instances should be named $eventManager, I believe.

While a shorthand  might be useful if one is short in time, it's not so useful in conveying what the object referred to really is. I know that this has been done very often when referring to Doctrine's EventManager ($em), but I don't think it's good practice.

> It might be hectic in some places in the manual, however I am unable to determine if it's messed up enough to be confusing for beginners. Better ask some genuine beginner about that….

I'm a ZF2 beginner - and I find it both confusing and inconsistent. That's the same for instances of the ServiceManager or ServiceLocator or instances implementing the ServiceLocatorInterface.


Best regards,

Andreas
--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

Artur Bodera
On Tue, Nov 13, 2012 at 11:48 AM, Andreas Möller <[hidden email]> wrote:

> And that's the point - most occurrences refer to instances of
> EventManager, rather than - what one would expect from the naming - a
> collection of events, an array of events, etc. To make it more clear what
> it *really* is, instances should be named $eventManager, I believe.
>

Ok, now I know what you're expecting.

So in this case, it's a shorthand based on the objective (as opposed to a
shorhand based purely on full name).

I.e.

$this->events->trigger()
$this->events->attach()
$this->events->detach()

It's just like saying "trigger some events" (which of course is not 100%
accurate, but is close to natural language),
"attach something to events" and finally
"detach something from events".

I do not see any purpose for having a separate "collection/array of events"
as opposed to EventManager. EventManager _is_ a collection of events in
that sense (it contains a number of events and listeners).


--
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

Andreas Möller
Hello Artur,


> So in this case, it's a shorthand based on the objective (as opposed to a shorhand based purely on full name).
>
> I.e.
>
> $this->events->trigger()
> $this->events->attach()
> $this->events->detach()
>
> It's just like saying "trigger some events" (which of course is not 100% accurate, but is close to natural language),
> "attach something to events" and finally
> "detach something from events".

But what actually is happening is that an event is attached to or detached from the event manager.

> I do not see any purpose for having a separate "collection/array of events" as opposed to EventManager. EventManager _is_ a collection of events in that sense (it contains a number of events and listeners).

Yes, I understand. But, as a matter of fact, though, the event manager has an array of events - but it isn't. It's called EventManager, after all - not Events.

For example, when I instantiate a form, I would refer to it as a form, not as elements - even though it is a container of form elements.


Best regards,

Andreas
--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

weierophinney
Administrator
In reply to this post by Andreas Möller
-- Andreas Möller <[hidden email]> wrote
(on Tuesday, 13 November 2012, 10:38 AM +0100):
> may I ask why instances of EventManager are referred to as events,
> rather than eventManager?

If you're talking about the _protected_ property, or the fact that many
setEventManager() implementations use "$events" as the name of the
EventManager property, or even that many examples will use constructs
like "$events = $object->getEventManager();" it's simply because:

 a) it's shorter to type
 b) it has a semantic affinity to how other languages (esp. JavaScript)
    refer to event collections/managers.

In JavaScript, you typically work with an "events" collection, and
attach/trigger from that; we chose terminology that should be familiar
to those familiar with that paradigm (which will be a majority of web
developers).

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

Andreas Möller
Hello Matthew,


> If you're talking about the _protected_ property, or the fact that many
> setEventManager() implementations use "$events" as the name of the
> EventManager property, or even that many examples will use constructs
> like "$events = $object->getEventManager();" it's simply because:
>
> a) it's shorter to type
> b) it has a semantic affinity to how other languages (esp. JavaScript)
>    refer to event collections/managers.

But it doesn't reveal what it really is - it is not a list of events, it's an instance of EventManager . . . !

Why is the EventManager class then named EventManager, not Events?

> In JavaScript, you typically work with an "events" collection, and
> attach/trigger from that; we chose terminology that should be familiar
> to those familiar with that paradigm (which will be a majority of web
> developers).

Still, it's an event manager.


Best regards,

Andreas



--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

weierophinney
Administrator
-- Andreas Möller <[hidden email]> wrote
(on Tuesday, 13 November 2012, 03:48 PM +0100):

> > If you're talking about the _protected_ property, or the fact that many
> > setEventManager() implementations use "$events" as the name of the
> > EventManager property, or even that many examples will use constructs
> > like "$events = $object->getEventManager();" it's simply because:
> >
> > a) it's shorter to type
> > b) it has a semantic affinity to how other languages (esp. JavaScript)
> >    refer to event collections/managers.
>
> But it doesn't reveal what it really is - it is not a list of events,
> it's an instance of EventManager . . . !
>
> Why is the EventManager class then named EventManager, not Events?

It aggregates listeners and triggers events; it could have been named
either way, to be honest. "EventManager" is cumbersome as a variable
name, but perfectly fine as a class name.

> > In JavaScript, you typically work with an "events" collection, and
> > attach/trigger from that; we chose terminology that should be familiar
> > to those familiar with that paradigm (which will be a majority of web
> > developers).
>
> Still, it's an event manager.

Honestly, I've never heard anybody else complain about it. At this
point, I'm not about to change all occurrences of it, either.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

Andreas Möller
Hello Matthew,


> It aggregates listeners and triggers events; it could have been named
> either way, to be honest. "EventManager" is cumbersome as a variable
> name, but perfectly fine as a class name.

I bet there are variables with names that are much longer eventManager. With auto-completion, length of class properties or variable names shouldn't be an issue.

A car aggregates passengers as well, but it's still called a car, not passengers.

> Honestly, I've never heard anybody else complain about it.

This doesn't invalidate my complaint, though.

> At this
> point, I'm not about to change all occurrences of it, either.

As this naming scheme is consistent throughout the project, I guess it doesn't make sense to complain concerning other managers, either?


Best regards,

Andreas
--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

weierophinney
Administrator
-- Andreas Möller <[hidden email]> wrote
(on Tuesday, 13 November 2012, 04:16 PM +0100):

> > It aggregates listeners and triggers events; it could have been named
> > either way, to be honest. "EventManager" is cumbersome as a variable
> > name, but perfectly fine as a class name.
>
> I bet there are variables with names that are much longer
> eventManager. With auto-completion, length of class properties or
> variable names shouldn't be an issue.
>
> A car aggregates passengers as well, but it's still called a car, not
> passengers.
>
> > Honestly, I've never heard anybody else complain about it.
>
> This doesn't invalidate my complaint, though.
>
> > At this
> > point, I'm not about to change all occurrences of it, either.
>
> As this naming scheme is consistent throughout the project, I guess it
> doesn't make sense to complain concerning other managers, either?

We often abbreviate ServiceManager to $services (or, in the case of
plugin managers, "$helpers", "$plugins", "$controllers"). If we were to
make the change for the event manager, I'd expect we'd have to rename
them everywhere. This is a pretty substantial refactor for basically
zero gain (it's an implementation detail only), and a whole lot of risk
(miss one location, and an entire test suite or component may no longer
work).

The variable names need only have a semantic meaning; they don't need to
always be completely, explicitly, literally named. Short semantic names
are a reasonable shortcut for readability of the code.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

Andreas Möller

> We often abbreviate ServiceManager to $services (or, in the case of
> plugin managers, "$helpers", "$plugins", "$controllers"). If we were to
> make the change for the event manager, I'd expect we'd have to rename
> them everywhere.

That would make sense, yes.

> This is a pretty substantial refactor for basically
> zero gain (it's an implementation detail only), and a whole lot of risk
> (miss one location, and an entire test suite or component may no longer
> work).

It's not zero gain. If components were named after what they are and not after what they are composed of, it would help beginners to understand the code better.

To me this naming scheme seems like a bad decision.

> The variable names need only have a semantic meaning; they don't need to
> always be completely, explicitly, literally named. Short semantic names
> are a reasonable shortcut for readability of the code.

"Events" doesn't have the same meaning as "EventManager" - at least not to me. These naming shortcuts do not help with understanding the code at all, seriously. What exactly is gained from using these shortcuts? Less typing time? Less reading time? A quicker understanding?


Best regards,

Andreas
--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

mpinkston
Hi Andreas,

I hope I don't end up confusing the issue here, but I'd like to offer one explanation for the naming (at least as I've used it).

There are two different contexts by which I'll look at any library component when I'm building a system.

During the analysis phase, I only consider the behavior of each component rather than the values it may or may not contain. In this case, the EventManager is a class which manages an untyped collection of labeled callables, and decides what to do with them during run-time.
With my own naming convention, I almost always call this type of class a manager because it is so much easier to understand in my class diagrams.

However, when I'm actually coding, I switch to a run-time method of thinking. I'm not as interested in the EventManager object itself, but rather the collection of events it contains, so I naturally just call the instance 'events'.

It can definitely be confusing if you're frequently switching between role of the analyst and developer, but I've personally found it to make things much clearer for me in the long run.
(just my 2¢)

Cheers,
-Matt P.
Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

weierophinney
Administrator
In reply to this post by Andreas Möller
-- Andreas Möller <[hidden email]> wrote
(on Tuesday, 13 November 2012, 08:38 PM +0100):

> > We often abbreviate ServiceManager to $services (or, in the case of
> > plugin managers, "$helpers", "$plugins", "$controllers"). If we were to
> > make the change for the event manager, I'd expect we'd have to rename
> > them everywhere.
>
> That would make sense, yes.
>
> > This is a pretty substantial refactor for basically
> > zero gain (it's an implementation detail only), and a whole lot of risk
> > (miss one location, and an entire test suite or component may no longer
> > work).
>
> It's not zero gain. If components were named after what they are and
> not after what they are composed of, it would help beginners to
> understand the code better.
>
> To me this naming scheme seems like a bad decision.
>
> > The variable names need only have a semantic meaning; they don't need to
> > always be completely, explicitly, literally named. Short semantic names
> > are a reasonable shortcut for readability of the code.
>
> "Events" doesn't have the same meaning as "EventManager" - at least
> not to me. These naming shortcuts do not help with understanding the
> code at all, seriously. What exactly is gained from using these
> shortcuts? Less typing time? Less reading time? A quicker
> understanding?

I think we need to agree to disagree at this point. It's clear you feel
strongly about the naming. I feel equally strongly that this is a change
that (a) could lead to some serious BC breaks and/or testing issues due
to the shear number of changes that would need to be reviewed, and (b)
would provide negligible benefit in light of (a). 3.0 would be an
appropriate time to bring this up; weeks after a stable release is not
the time.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

RE: Events vs. EventManager

BullfrogBlues
In reply to this post by weierophinney

> Date: Tue, 13 Nov 2012 09:03:18 -0600
> From: [hidden email]
> To: [hidden email]
> Subject: Re: [fw-general] Events vs. EventManager
>
> -- Andreas Möller <[hidden email]> wrote
> (on Tuesday, 13 November 2012, 03:48 PM +0100):
> > > If you're talking about the _protected_ property, or the fact that many
> > > setEventManager() implementations use "$events" as the name of the
> > > EventManager property, or even that many examples will use constructs
> > > like "$events = $object->getEventManager();" it's simply because:
> > >
> > > a) it's shorter to type
> > > b) it has a semantic affinity to how other languages (esp. JavaScript)
> > >    refer to event collections/managers.
> >
> > But it doesn't reveal what it really is - it is not a list of events,
> > it's an instance of EventManager . . . !
> >
> > Why is the EventManager class then named EventManager, not Events?
>
> It aggregates listeners and triggers events; it could have been named
> either way, to be honest. "EventManager" is cumbersome as a variable
> name, but perfectly fine as a class name.
>
> > > In JavaScript, you typically work with an "events" collection, and
> > > attach/trigger from that; we chose terminology that should be familiar
> > > to those familiar with that paradigm (which will be a majority of web
> > > developers).
> >
> > Still, it's an event manager.
>
> Honestly, I've never heard anybody else complain about it. At this
> point, I'm not about to change all occurrences of it, either.
>
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

I agree with some of his points. You haven't heard me complain because I've stopped caring about these kind of things. I don't advocate changing these things at this stage either. zf3 is the place for that.

--
Gerard
     
Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

Andreas Möller
> I agree with some of his points. You haven't heard me complain because I've stopped caring about these kind of things. I don't advocate changing these things at this stage either. zf3 is the place for that.

For issues like the one discussed here, shall an issue be created on Github?


Best regards,

Andreas
--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

RE: Events vs. EventManager

BullfrogBlues
> From: [hidden email]
> Date: Wed, 14 Nov 2012 14:13:30 +0100
> CC: [hidden email]; [hidden email]
> To: [hidden email]
> Subject: Re: [fw-general] Events vs. EventManager
>
> > I agree with some of his points. You haven't heard me complain because I've stopped caring about these kind of things. I don't advocate changing these things at this stage either. zf3 is the place for that.
>
> For issues like the one discussed here, shall an issue be created on Github?
>
>
> Best regards,
>
> Andreas
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]

That's an interesting approach. I'm not sure. Discussions on issues like this can go on for ever. I think it will be better to disable the discussion in the issue tracker and just link to relating resources instead.

Add tags "review-for-zf3", "tbd-zf3" or something like that. Then encourage discussions of issues like this as development on the relating version starts.
     
Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

Andreas Möller
Hello Gerry,


> That's an interesting approach. I'm not sure. Discussions on issues like this can go on for ever. I think it will be better to disable the discussion in the issue tracker and just link to relating resources instead.

From what, though?

> Add tags "review-for-zf3", "tbd-zf3" or something like that. Then encourage discussions of issues like this as development on the relating version starts.

Sounds good to me. Otherwise, decisions will probably be made on IRC or wherever. I can't add any labels to issues, though, it seems.


Best regards,

Andreas
Reply | Threaded
Open this post in threaded view
|

RE: Events vs. EventManager

BullfrogBlues


> From: [hidden email]
> Date: Wed, 14 Nov 2012 14:53:49 +0100
> CC: [hidden email]; [hidden email]
> To: [hidden email]
> Subject: Re: [fw-general] Events vs. EventManager
>
> Hello Gerry,
>
>
> > That's an interesting approach. I'm not sure. Discussions on issues like this can go on for ever. I think it will be better to disable the discussion in the issue tracker and just link to relating resources instead.
>
> From what, though?

???

How do you mean "from what"?

> > Add tags "review-for-zf3", "tbd-zf3" or something like that. Then encourage discussions of issues like this as development on the relating version starts.
>
> Sounds good to me. Otherwise, decisions will probably be made on IRC or wherever. I can't add any labels to issues, though, it seems.
>
>
> Best regards,
>
> Andreas


 
     
Reply | Threaded
Open this post in threaded view
|

Re: Events vs. EventManager

Andreas Möller
Hello Gerry,


> > > That's an interesting approach. I'm not sure. Discussions on issues like this can go on for ever. I think it will be better to disable the discussion in the issue tracker and just link to relating resources instead.
> >
> > From what, though?
>
> ???
>
> How do you mean "from what"?


You said that one should just link to the relating sources. But where should the link be placed - e.g. from where shall one link to the related resources?

And, what would a related resource be - a link to Nabble?


Best regards,

Andreas

Reply | Threaded
Open this post in threaded view
|

RE: Events vs. EventManager

BullfrogBlues





> From: [hidden email]
> Date: Wed, 14 Nov 2012 15:10:29 +0100
> CC: [hidden email]; [hidden email]
> To: [hidden email]
> Subject: Re: [fw-general] Events vs. EventManager
>
> Hello Gerry,
>
>
> > > > That's an interesting approach. I'm not sure. Discussions on issues like this can go on for ever. I think it will be better to disable the discussion in the issue tracker and just link to relating resources instead.
> > >
> > > From what, though?
> >
> > ???
> >
> > How do you mean "from what"?
> You said that one should just link to the relating sources. But where should the link be placed - e.g. from where shall one link to the related resources?
>
> And, what would a related resource be - a link to Nabble?
>
>
> Best regards,
>
> Andreas
>

Ah, yes. I'm not sure.

What I am sure about is this: I don't want to waste my time debating issues like coding standards. I
have an opinion on what I like so I'll vote and sometimes even throw in
my 2cents about which side of the fench I sit on. Some people do like
discussing these things though. Trying to convince us all that their way
 is the best. I'm fine with that. Convince me I'll vote for it. At the same time, that
doesn't mean discussing things like coding standards is a
waste of time. It is counter productive to allow
discussions like this to be open indefinitly though. They should be closed and
only open for short periods of time when a decision needs to be made. I'd like to be notified too i.e. when
discussions for a particular topic of interest are open and active.

I guess the github issue tracker will probably works best for this kind of thing. Not ideal, but close.

* You can keep the
dicussion part of the issue closed and then open it at the appropriate
time.
* You can watch an issue in github, so that kinda notifies you
when it opens.

If duplicates open on nabble or anywhere else. Close them. Post a link to the github issue. And a link in the issue back to the duplicate. The issue should
 explain why the dicussion is currently closed and when it will be opened.

... or something like that. :)

Regards,

Gerard




     
12