(04-28-2015, 02:40 PM)dmyers Wrote: I wanted to make my event library fast and use the least amount of memory as possible and therefore didn't feel the extra overhead to register the expected variables and the expected types (one or more) as well as verifying the input when it's sent in to make sure it matches the expected variables and types would be worth that overhead.
I'm not saying that the library itself needs to be aware of and/or enforce these requirements. The code which calls your library to trigger an event should ensure the data is valid according to whatever documented specification exists for that event before triggering it. In theory, any code subscribing to that event is using the same specification. All of this assumes a situation in which it is more important to be fast and use the least amount of memory possible, because the alternative would be to define an interface or abstract class for the event's payload (so the structure of the data would be enforced by the interface/class definition).
(04-28-2015, 02:40 PM)dmyers Wrote: I say multiple types because $user_id = '123' & $user_id = 123 & $user_id = null are all valid options in my example code.
Any "automatic" validator on $data should allow this as well.
Heck mine actually could be used in a method overloading fashion if you wanted:
$array_of_people = ['joe','john'];
ci()->event->trigger('add_people',$array_of_people);
$single = 'joe';
ci()->event->trigger('add_people',$single);
This should valid as well no?
If that flexibility is desired in that particular event, the event's payload should be defined as such. Otherwise, your subscriber will be expecting the payload to be an array and will receive a string. If it doesn't check the type of the argument, it may well trigger an exception by treating the string as an array (or, worse, it may silently manipulate the string in unexpected ways).
None of this is changed by passing more arguments to the function. Further, if any given variable in your string of arguments can be of multiple types, you start to lose the performance improvement you claim to gain by passing multiple arguments, because each subscriber has to check the type of any variable which might require different treatment based on type.
(04-28-2015, 02:40 PM)dmyers Wrote: Also I'm not sure what you mean by the following:
"and, if a subscriber doesn't do so, you may still get an unhandled exception)."
I have full error_reporting(-1) (codeIgniter Default for development) in index.php
and it doesn't throw a unhandled exception? maybe my version of PHP (5.5.17) handles it differently.
I meant "unhandled exception" in the sense that you're relying on CodeIgniter's exception handler to catch it, rather than preventing it in the first place or catching it yourself.
If a subscriber is expecting $e to be an array, receives null, and doesn't check is_null($e) or is_array($e) (or whatever type checking you choose) before applying certain functions to $e, you're going to end up with an exception.
(04-28-2015, 02:40 PM)dmyers Wrote: I would be interested in comparing your library with mine in regards to speed and memory.
I'm simply speaking in general terms, but you can look at the majority of mature PHP event libraries and find that most of them use 2 or 3 arguments in their trigger methods: the name of the event, the payload, and maybe an argument to prevent event bubbling (for libraries modeled on the HTML/JavaScript DOM style of event handling).
I haven't profiled Bonfire's Events library, but that's primarily because it hasn't attracted my attention when profiling problematic pages (I didn't write the library, either, but there's not much stopping me from rewriting it if I see a reason to do so). It operates on an assumption that the subscriber may be in a file which is not loaded until the event is triggered, which may create its own performance trade-offs. This also precludes the possibility of using a closure as a subscriber, though it probably wouldn't be difficult to add that option.
