EventManager priorities

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

EventManager priorities

mbn18
Hi,

Over the IRC we discussed events priority ( Me, saschaH & Akrabat )

As I understand event with -100 priority is a post dispatch priority.

My opinion is that human logic prefer to see post as higher number then pre. So lower priority should run first.
I also think that the current priority will be a pit fall for most newbies.

I am in favor of reverting the priority behavior.

Any thoughts?

Cheers,
Michael / mbn_18

Reply | Threaded
Open this post in threaded view
|

Re: EventManager priorities

Marco Pivetta
"high priority" in computers is a "high number" :)
That is also how the SplPriorityQueue works (used internally by ZF2).
It would not make sense (and also be a bit complex) to just revert the values. Plus I (my opinion) agree that high priority = high value, while low priority = low value (negatives too).
Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 4 July 2012 22:14, Michael Ben-Nes <[hidden email]> wrote:
Hi,

Over the IRC we discussed events priority ( Me, saschaH & Akrabat )

As I understand event with -100 priority is a post dispatch priority.

My opinion is that human logic prefer to see post as higher number then pre. So lower priority should run first.
I also think that the current priority will be a pit fall for most newbies.

I am in favor of reverting the priority behavior.

Any thoughts?

Cheers,
Michael / mbn_18


Reply | Threaded
Open this post in threaded view
|

Re: EventManager priorities

weierophinney
Administrator
In reply to this post by mbn18
-- Michael Ben-Nes <[hidden email]> wrote
(on Wednesday, 04 July 2012, 11:14 PM +0300):

> Over the IRC we discussed events priority ( Me, saschaH & Akrabat )
>
> As I understand event with -100 priority is a post dispatch priority.
>
> My opinion is that human logic prefer to see post as higher number then pre. So
> lower priority should run first.
> I also think that the current priority will be a pit fall for most newbies.
>
> I am in favor of reverting the priority behavior.
>
> Any thoughts?

In computing, priority is typically dealt with using integers. Integers
of higher value indicate higher priority.

The situation you refer to, where a lower numbers indicate earlier
execution and higher numbers indicate later execution is not priority,
it's more on the order of ordinality.

Internally, we use SplPriorityQueue for our implementation. This
solution makes it trivially simple to add events at a given priority, as
well as ensure the execute at that priority.

Reverting priority behavior at this point will mean:

 * We now need to code the insertion logic ourselves. This adds
   complexity and another vector for bugs.

 * We lose on the performance benefits of using the SPL data structure.

 * Priority no longer means priority. It means "order". So, we'd not
   only be reverting the behavior, but the semantic meaning.

I think we stand to lose a lot by changing at this 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
Reply | Threaded
Open this post in threaded view
|

Re: EventManager priorities

Artur Bodera
On Thu, Jul 5, 2012 at 4:48 PM, Matthew Weier O'Phinney <[hidden email]> wrote:
-- Michael Ben-Nes <[hidden email]> wrote
(on Wednesday, 04 July 2012, 11:14 PM +0300):
> Over the IRC we discussed events priority ( Me, saschaH & Akrabat )
>
> As I understand event with -100 priority is a post dispatch priority.
>
> My opinion is that human logic prefer to see post as higher number then pre. So
> lower priority should run first.
> I also think that the current priority will be a pit fall for most newbies.
>
> I am in favor of reverting the priority behavior.
>
> Any thoughts?

In computing, priority is typically dealt with using integers. Integers
of higher value indicate higher priority.

The situation you refer to, where a lower numbers indicate earlier
execution and higher numbers indicate later execution is not priority,
it's more on the order of ordinality.

Internally, we use SplPriorityQueue for our implementation. This
solution makes it trivially simple to add events at a given priority, as
well as ensure the execute at that priority.

Reverting priority behavior at this point will mean:

 * We now need to code the insertion logic ourselves. This adds
   complexity and another vector for bugs.

 * We lose on the performance benefits of using the SPL data structure.

 * Priority no longer means priority. It means "order". So, we'd not
   only be reverting the behavior, but the semantic meaning.

I think we stand to lose a lot by changing at this time.


I've witnessed Matthew skimming through code trying to find the exact 
number for a priority, in to help somebody introduce custom listener.

A simple suggestion: introduce a couple of constants to make it easier
to override default behaviors.

I.e.  
SplPriorityQueue::PRIORITY_HIGH = 10000;
SplPriorityQueue::PRIORITY_NORMAL = 100;
SplPriorityQueue::PRIORITY_LOW = 0;

Or those could go inside MvcEvent class, or somewhere else.

The principle is similar to constants for events inside Mvc.


-- 
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]




 
Reply | Threaded
Open this post in threaded view
|

Re: EventManager priorities

weierophinney
Administrator
-- Artur Bodera <[hidden email]> wrote
(on Friday, 06 July 2012, 01:22 PM +0200):

> On Thu, Jul 5, 2012 at 4:48 PM, Matthew Weier O'Phinney <[hidden email]>
> wrote:
>
>     -- Michael Ben-Nes <[hidden email]> wrote
>     (on Wednesday, 04 July 2012, 11:14 PM +0300):
>     > Over the IRC we discussed events priority ( Me, saschaH & Akrabat )
>     >
>     > As I understand event with -100 priority is a post dispatch priority.
>     >
>     > My opinion is that human logic prefer to see post as higher number then
>     pre. So
>     > lower priority should run first.
>     > I also think that the current priority will be a pit fall for most
>     newbies.
>     >
>     > I am in favor of reverting the priority behavior.
>     >
>     > Any thoughts?
>
>     In computing, priority is typically dealt with using integers. Integers
>     of higher value indicate higher priority.
>
>     The situation you refer to, where a lower numbers indicate earlier
>     execution and higher numbers indicate later execution is not priority,
>     it's more on the order of ordinality.
>
>     Internally, we use SplPriorityQueue for our implementation. This
>     solution makes it trivially simple to add events at a given priority, as
>     well as ensure the execute at that priority.
>
>     Reverting priority behavior at this point will mean:
>
>      * We now need to code the insertion logic ourselves. This adds
>        complexity and another vector for bugs.
>
>      * We lose on the performance benefits of using the SPL data structure.
>
>      * Priority no longer means priority. It means "order". So, we'd not
>        only be reverting the behavior, but the semantic meaning.
>
>     I think we stand to lose a lot by changing at this time.
>
>
>
> I've witnessed Matthew skimming through code trying to find the exact
> number for a priority, in to help somebody introduce custom listener.
>
> A simple suggestion: introduce a couple of constants to make it easier
> to override default behaviors.
>
> I.e.  
> SplPriorityQueue::PRIORITY_HIGH = 10000;
> SplPriorityQueue::PRIORITY_NORMAL = 100;
> SplPriorityQueue::PRIORITY_LOW = 0;
>
> Or those could go inside MvcEvent class, or somewhere else.
>
> The principle is similar to constants for events inside Mvc.

I've actually been considering constants for all specific priorities
listeners currently register on already -- for the exact reasons you
mention. I'll likely slip this in before RC1 is ready.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: EventManager priorities

EvanDotPro
In reply to this post by Artur Bodera
On Fri, Jul 6, 2012 at 4:22 AM, Artur Bodera <[hidden email]> wrote:
On Thu, Jul 5, 2012 at 4:48 PM, Matthew Weier O'Phinney <[hidden email]> wrote:
-- Michael Ben-Nes <[hidden email]> wrote
(on Wednesday, 04 July 2012, 11:14 PM +0300):
> Over the IRC we discussed events priority ( Me, saschaH & Akrabat )
>
> As I understand event with -100 priority is a post dispatch priority.
>
> My opinion is that human logic prefer to see post as higher number then pre. So
> lower priority should run first.
> I also think that the current priority will be a pit fall for most newbies.
>
> I am in favor of reverting the priority behavior.
>
> Any thoughts?

In computing, priority is typically dealt with using integers. Integers
of higher value indicate higher priority.

The situation you refer to, where a lower numbers indicate earlier
execution and higher numbers indicate later execution is not priority,
it's more on the order of ordinality.

Internally, we use SplPriorityQueue for our implementation. This
solution makes it trivially simple to add events at a given priority, as
well as ensure the execute at that priority.

Reverting priority behavior at this point will mean:

 * We now need to code the insertion logic ourselves. This adds
   complexity and another vector for bugs.

 * We lose on the performance benefits of using the SPL data structure.

 * Priority no longer means priority. It means "order". So, we'd not
   only be reverting the behavior, but the semantic meaning.

I think we stand to lose a lot by changing at this time.


I've witnessed Matthew skimming through code trying to find the exact 
number for a priority, in to help somebody introduce custom listener.

A simple suggestion: introduce a couple of constants to make it easier
to override default behaviors.

I.e.  
SplPriorityQueue::PRIORITY_HIGH = 10000;
SplPriorityQueue::PRIORITY_NORMAL = 100;
SplPriorityQueue::PRIORITY_LOW = 0;

+1, I quite like this idea!

Or those could go inside MvcEvent class, or somewhere else.


I'd prefer to see them somewhere more central, though.

---
Evan Coury, ZCE
Reply | Threaded
Open this post in threaded view
|

Re: EventManager priorities

mbn18
If I may suggest, I think we should include the words POST and PRE.
This is straight forward and follow common sense, imho.

Cheers,
Michael / mbn_18



On Fri, Jul 6, 2012 at 7:43 PM, Evan Coury <[hidden email]> wrote:
On Fri, Jul 6, 2012 at 4:22 AM, Artur Bodera <[hidden email]> wrote:
On Thu, Jul 5, 2012 at 4:48 PM, Matthew Weier O'Phinney <[hidden email]> wrote:
-- Michael Ben-Nes <[hidden email]> wrote
(on Wednesday, 04 July 2012, 11:14 PM +0300):
> Over the IRC we discussed events priority ( Me, saschaH & Akrabat )
>
> As I understand event with -100 priority is a post dispatch priority.
>
> My opinion is that human logic prefer to see post as higher number then pre. So
> lower priority should run first.
> I also think that the current priority will be a pit fall for most newbies.
>
> I am in favor of reverting the priority behavior.
>
> Any thoughts?

In computing, priority is typically dealt with using integers. Integers
of higher value indicate higher priority.

The situation you refer to, where a lower numbers indicate earlier
execution and higher numbers indicate later execution is not priority,
it's more on the order of ordinality.

Internally, we use SplPriorityQueue for our implementation. This
solution makes it trivially simple to add events at a given priority, as
well as ensure the execute at that priority.

Reverting priority behavior at this point will mean:

 * We now need to code the insertion logic ourselves. This adds
   complexity and another vector for bugs.

 * We lose on the performance benefits of using the SPL data structure.

 * Priority no longer means priority. It means "order". So, we'd not
   only be reverting the behavior, but the semantic meaning.

I think we stand to lose a lot by changing at this time.


I've witnessed Matthew skimming through code trying to find the exact 
number for a priority, in to help somebody introduce custom listener.

A simple suggestion: introduce a couple of constants to make it easier
to override default behaviors.

I.e.  
SplPriorityQueue::PRIORITY_HIGH = 10000;
SplPriorityQueue::PRIORITY_NORMAL = 100;
SplPriorityQueue::PRIORITY_LOW = 0;

+1, I quite like this idea!

Or those could go inside MvcEvent class, or somewhere else.


I'd prefer to see them somewhere more central, though.

---
Evan Coury, ZCE

Reply | Threaded
Open this post in threaded view
|

Re: EventManager priorities

till
I'd vote for "BEFORE" and "AFTER". :)

On Sunday, July 8, 2012 at 12:18 AM, Michael Ben-Nes wrote:

> If I may suggest, I think we should include the words POST and PRE.
> This is straight forward and follow common sense, imho.
>
> Cheers,
> Michael / mbn_18
>
>
>
>
> On Fri, Jul 6, 2012 at 7:43 PM, Evan Coury <[hidden email] (mailto:[hidden email])> wrote:
> > On Fri, Jul 6, 2012 at 4:22 AM, Artur Bodera <[hidden email] (mailto:[hidden email])> wrote:
> > > On Thu, Jul 5, 2012 at 4:48 PM, Matthew Weier O'Phinney <[hidden email] (mailto:[hidden email])> wrote:
> > > > -- Michael Ben-Nes <[hidden email] (mailto:[hidden email])> wrote
> > > > (on Wednesday, 04 July 2012, 11:14 PM +0300):
> > > > > Over the IRC we discussed events priority ( Me, saschaH & Akrabat )
> > > > >
> > > > > As I understand event with -100 priority is a post dispatch priority.
> > > > >
> > > > > My opinion is that human logic prefer to see post as higher number then pre. So
> > > > > lower priority should run first.
> > > > > I also think that the current priority will be a pit fall for most newbies.
> > > > >
> > > > > I am in favor of reverting the priority behavior.
> > > > >
> > > > > Any thoughts?
> > > >
> > > > In computing, priority is typically dealt with using integers. Integers
> > > > of higher value indicate higher priority.
> > > >
> > > > The situation you refer to, where a lower numbers indicate earlier
> > > > execution and higher numbers indicate later execution is not priority,
> > > > it's more on the order of ordinality.
> > > >
> > > > Internally, we use SplPriorityQueue for our implementation. This
> > > > solution makes it trivially simple to add events at a given priority, as
> > > > well as ensure the execute at that priority.
> > > >
> > > > Reverting priority behavior at this point will mean:
> > > >
> > > > * We now need to code the insertion logic ourselves. This adds
> > > > complexity and another vector for bugs.
> > > >
> > > > * We lose on the performance benefits of using the SPL data structure.
> > > >
> > > > * Priority no longer means priority. It means "order". So, we'd not
> > > > only be reverting the behavior, but the semantic meaning.
> > > >
> > > > I think we stand to lose a lot by changing at this time.
> > >
> > > I've witnessed Matthew skimming through code trying to find the exact
> > > number for a priority, in to help somebody introduce custom listener.
> > >
> > > A simple suggestion: introduce a couple of constants to make it easier
> > > to override default behaviors.
> > >
> > > I.e.
> > > SplPriorityQueue::PRIORITY_HIGH = 10000;
> > > SplPriorityQueue::PRIORITY_NORMAL = 100;
> > > SplPriorityQueue::PRIORITY_LOW = 0;
> >
> >
> >
> > +1, I quite like this idea!
> >
> > > Or those could go inside MvcEvent class, or somewhere else.
> >
> > I'd prefer to see them somewhere more central, though.
> >
> > ---
> > Evan Coury, ZCE
> > http://blog.evan.pro/ 
>



Reply | Threaded
Open this post in threaded view
|

Re: EventManager priorities

Artur Bodera
On Sun, Jul 8, 2012 at 12:59 AM, till <[hidden email]> wrote:
I'd vote for "BEFORE" and "AFTER". :)

There's little need for that. It's a range:

If HIGH = 10000 and NORMAL = 1000, then
BEFORE_HIGH (or PRE_HIGH) is everything between 1001 and 9999 in that stack.

You need prefixes only in case when priorities are preset (i.e. they are not int-based,
but rather 5 priorities and nothing in between). We do have a priority queue internally,
so the ordering is up to the developer.

In case large number of modules start popping up, their authors could:

1) Scan source code for similar/conflicting modules to find priority and -/+ a little.
2) Agree on some common constant name and fetch it, i.e.:

    FooModule::LISTENER1_PRIORITY = 1040;

    BarModule { 
        function initEvents($em){ 
            $em->attach(array($this,'foo'),  FooModule::LISTENER1_PRIORITY - 10);
        }
    }

A.