I like you, hongzh2002, I'm a little disappoint that this is been so slow in developing. If it had already been approved and implement by someone like Monolog did with PSR-3 I probably wouldn't have made my own. Making my own wasn't really a waste of time either for me as I learned a lot of things in the process but I could have used the time on other projects as well too.
Just a couple comments on your ideas about changes to consider hongzh2002. on 1 and 2 using null would be a bad idea because it would make it so one small typo goes from cause easy to catch errors or exception to trying to figure out why your events aren't being sent to the registered callbacks / handlers anymore. Given the syntax you proposed if I was try to just remove one listener like this 'detach($event, $calback);' I have a problem. Did you notice the problem? instead of spelling it $callback with 2 Ls it had one. PHP just trying to be helpful decides I want a new variable and give me one with a value of null. So now instead of removing one thing I could break everything. With the original proposed way of doing things most implementations are going to either log an error or throw an exception when it receives null instead of the expected callable. Another value that might be better in your proposed change is false instead which doesn't have the same hazards I just covered. Personally I only see having the detach() and clearListeners() for completeness only, as once I attach() to an event I did so to receive all of them that come along until the whole process ends but I guess there might be a few cases where you only want to attach for the first one then detach etc. 3 I do think it needs to be settled on as well. The to ranges that come to mind for me would be that of an int with or without allowing negative numbers with larger numbers have the higher priority. Most existing implementation I've looked at use one of those ranges so for any that wanted to align with this PSR it would make doing so easiest to have the same range. The main question here is it a 32 or 64 bit int. I would say 32 bit is more than enough to require but allow implementation to extend to 64 bit if they want. That would allow anyone stuck with using 32 bit versions of PHP to use it but still allow more room for anyone else that thinks they really are going to be attaching more listeners then there are grains of sand on earth or stars in the universe ;) 4. I noticed too and I'm sure it's a cut and paste typo. 5. This is probably outside of the PSR as it's getting into the implementation details which shouldn't be included in one just like has been the case with all the PSRs. PSRs are meant to fully cover all implementation details they just set the minimum spec for inter-operation that everyone can use. Just like Monolog implements everything in PSR-3 but extends beyond it that would be expect here as well with the understanding that if you do use those things beyond the PSR you are binding yourself to a certain one and ignoring the reasons for the PSR to start with. 6. You have just made my point that by not having the payload be an object and having the additional things that can be added you are going down a slope that leads to lack of inter-operation that this PSR is trying to be solved. The payload needs to be a first class object to have any hope that different implementation can be dropped in to replace each other and all the other setters and getters dropped from it. I do understand for some people having to create yet other object just to pass a simple value seems like over kill but see it as more of a bad smell myself that you have a problem with you object structure if you are passing around a bare value with an event that needs to be fixed. 7. I agree having a default value of true makes sense here. On Fri, Jul 15, 2016 at 4:42 AM, <hongzh2...@gmail.com> wrote: > Just noticed the PSR event manager proposal and took a look at it today. > Frankly speaking, I was disappointed at its current achievement, consider > it's almost 2 years for this thread. here are the questions I have > regarding the PSR event manager proposal. > > 1. why not use 'detach($event, $callback = null)' to replace > 'clearListeners()' ? > 2. How to clear all events ? how about 'detach($event = '', $callback = > null)' ? > 3. $priority higher value means higher priority ? anything about its range > ? > 4. typo: detach()'s phpdoc @param string $event the event to attach too ? > 5. why no sanity checking on event name input ? what if it is not valid, > why not throw an expection ? > 6. why no 'setParam($name, $value)', what if a handler want to set a > single value ? > 7. why no default value 'true' for public function stopPropagation($flag) ? > > HZ > > 在 2014年7月21日星期一 UTC+8上午4:40:33，Chuck Reeves写道： >> >> Back at PHPTek, @crell asked if there were any ideas out there for new >> FIG standards. I came up with the idea of having an Event Manager Interface >> through FIG. >> >> I took a look at Symfony, Zend Framework 2 and Doctrine to see how they >> work then started an early draft. I made mention of it on twitter and >> started getting some feedback. I figured I would start a conversation here >> to avoid the limitations of twitter and incorporate those ideas into the >> draft. Here is the link to what I came up with so far: >> https://github.com/manchuck/fig-standards/blob/master/proposed/event-manager.md >> >> The 1st reaction was with the use of getName. Symfony 3 is moving away >> from using it in favor of using objects. My initial thought for including >> getName in EventInterface, was to allow implementer to build an event using >> EventInterface and then pass that in to the EventManagerInterface::trigger >> >> I do not know of any other frameworks use an event manager out there. I >> would appreciate any feedback on my initial draft as well as insight into >> other frameworks out there that use events. >> >> Thanks >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/php-fig/-EJOStgxAwY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/05d1ed4d-6670-4270-b10f-5e17655bb75b%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/05d1ed4d-6670-4270-b10f-5e17655bb75b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAP9GSfXtgJeDCbFp_XR0LbhHONn_MFXk65g370shfQQnPZgQmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
