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

[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

[weierophinney]

-- 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

[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.

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

 

[weierophinney]

-- 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

[EvanDotPro]

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

http://blog.evan.pro/

[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

http://blog.evan.pro/

[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/ 
>

[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.