Something can be a filter without having the name “filter”, and “filter” is an overloaded term and can mean different things. “guarded” is a filter because it filters, just like a guard is a filter since he or she says who can enter and who cannot. But a guard is not a water filter, nor is a cigarette filter, and none of those is the list filtering function “filter”.

Your class-based version kind of shows exactly why I prefer to solve a problem like this using higher order functions. That code is so much unnecessary extra code that doesn’t do anything besides creating a functor (i.e. an object that acts as a function). I understand that not every one knows functional programming idioms and get them straight away, but if you work in a language that has higher order functions why avoid using them? If someone doesn’t get the functional approach to solving a problem it’s too bad for them. If we shouldn’t do this or that because some may not understand we might as well limit ourselves to the feature set of Fortran.

“If you add the guarded listener on the stage for example you will have to remove the listener later or obj1 and obj2 will never be garbage collected.”

This is true for any event listener, your EventFilter too, so it’s hardly an argument. Use weak references or keep the listener around, that’s your options whichever way you decide to solve the problem.

Also you say it is filter but use ‘guarded’ as name.

I would prefer to use something like:

public class EventFilter { protected var _filter:Function; protected var _function:Function; public function EventFilter(theFilter:Function, theFunction:Function) { _filter = theFilter; _function = theFunction; } public function get handler(e:Event) { if (_filter(e)) _function(e) } }

Then assign listeners like:

var eventFilter = new EventFilter(_isEnterKey, _onSend) addEventListener(KeyboardEvent.KEY_UP, eventFilter.handler);

…

protected function _isEnterKey(e:Event) { … } protected function _onSend(e:Event) { form.send() }

If you have getter and setters defined on the EventFilter you would be able to change the filtering function and the handler.

Also that way it’s clear that you create an object that references the objects that own the filter and the function properties.

Some coders may miss the fact that the function returned by: guarded(obj1.someFilter, obj2.somehandler); would most probably reference the obj1 and obj2. If you add the guarded listener on the stage for example you will have to remove the listener later or obj1 and obj2 will never be garbage collected.

Anyway it’s only my point of view. You’ve done nice work on this article and I would love to see your higher order functions library :)

If you’re still leaning towards releasing your higher order functions library, I’d gladly contribute time to helping with documentation or testing. I have some array filtering classes of my own that might fit with such a library, too.

I was interested to see how you were going to modify sendButton.addEventListener(MouseEvent.CLICK, onSendButtonClicked);

but later you replaced it with sendButton.addEventListener(MouseEvent.CLICK, onSendForm);

ahh well.

guards are very general and there are absolutely better ways to solve specific cases.