/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Warning: Cannot modify header information - headers already sent by (output started at /customers/4/c/9/iconara.net/httpd.www/blog/wp-content/advanced-cache.php:1) in /customers/4/c/9/iconara.net/httpd.www/blog/wp-includes/feed-rss2-comments.php on line 8 Comments on: Separating event handling from event filtering http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/ Thu, 05 Jul 2012 13:41:39 +0000 hourly 1 http://wordpress.org/?v=3.0 By: mzx http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/comment-page-1/#comment-7816 mzx Thu, 30 Apr 2009 16:25:18 +0000 http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/#comment-7816 <p>nice one. and as u remember some flex components (TextInput) has different event handler for enter.. so to do as many events as u need is the correct approach imao</p> nice one. and as u remember some flex components (TextInput) has different event handler for enter.. so to do as many events as u need is the correct approach imao

]]>
By: Theo http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/comment-page-1/#comment-7796 Theo Thu, 09 Apr 2009 09:06:53 +0000 http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/#comment-7796 <p>It's not a constructor in the object-oriented sense. It's a function that returns a lambda, it's a common functional programming idiom.</p> <p>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".</p> <p>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.</p> <p><em>"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."</em></p> <p>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.</p> It’s not a constructor in the object-oriented sense. It’s a function that returns a lambda, it’s a common functional programming idiom.

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.

]]>
By: Panayot http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/comment-page-1/#comment-7793 Panayot Wed, 08 Apr 2009 18:05:09 +0000 http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/#comment-7793 <p>You are using kind of constructor but without new operator. The guarded returns a function object but you don't feel it as an object.</p> <p>Also you say it is filter but use 'guarded' as name.</p> <p>I would prefer to use something like:</p> <p>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) } }</p> <p>Then assign listeners like:</p> <p>var eventFilter = new EventFilter(_isEnterKey, _onSend) addEventListener(KeyboardEvent.KEY_UP, eventFilter.handler);</p> <p>...</p> <p>protected function _isEnterKey(e:Event) { ... } protected function _onSend(e:Event) { form.send() }</p> <p>If you have getter and setters defined on the EventFilter you would be able to change the filtering function and the handler.</p> <p>Also that way it's clear that you create an object that references the objects that own the filter and the function properties.</p> <p>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.</p> <p>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 :)</p> You are using kind of constructor but without new operator. The guarded returns a function object but you don’t feel it as an object.

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

]]>
By: Eric Greveson http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/comment-page-1/#comment-7530 Eric Greveson Wed, 03 Sep 2008 21:30:11 +0000 http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/#comment-7530 <p>I like the guard function method over the key mapper method (which I've been using up to now), it's more flexible and reminds me that I should be making use of first-class functions (I'm from a C++ background so I keep forgetting about them)! I'd like to see your higher order functions library being released too - simple, lightweight libraries that really improve the way people code are something that's mostly missing from the Flex community at the moment (although I've been trying Mate recently, after your recommendation, and it's pretty cool).</p> I like the guard function method over the key mapper method (which I’ve been using up to now), it’s more flexible and reminds me that I should be making use of first-class functions (I’m from a C++ background so I keep forgetting about them)! I’d like to see your higher order functions library being released too – simple, lightweight libraries that really improve the way people code are something that’s mostly missing from the Flex community at the moment (although I’ve been trying Mate recently, after your recommendation, and it’s pretty cool).

]]>
By: Tom Carden http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/comment-page-1/#comment-7262 Tom Carden Fri, 15 Aug 2008 06:03:36 +0000 http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/#comment-7262 <p>It took me a couple of attempts to fully understand the appeal of this approach, but I like it very much. It feels somehow "well rounded" :)</p> <p>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.</p> It took me a couple of attempts to fully understand the appeal of this approach, but I like it very much. It feels somehow “well rounded” :)

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.

]]>
By: Marcus Stade http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/comment-page-1/#comment-6971 Marcus Stade Sat, 05 Jul 2008 17:00:05 +0000 http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/#comment-6971 <p>I LOVE this concept, thank you very much for sharing! Great blog btw, just stumbled upon it.</p> I LOVE this concept, thank you very much for sharing! Great blog btw, just stumbled upon it.

]]>
By: Joshua E Cook http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/comment-page-1/#comment-6735 Joshua E Cook Fri, 16 May 2008 13:58:27 +0000 http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/#comment-6735 <p>Stephan, although your KeyMapper works elegantly for associating an action with a particular keycode, the guarding method is more flexible. Consider if you wanted to associate a different action for a keycode when the SHIFT or CTRL keys are held down. This would require significant changes to your KeyMapper class, but only a simple change to the guard function is required.</p> Stephan, although your KeyMapper works elegantly for associating an action with a particular keycode, the guarding method is more flexible. Consider if you wanted to associate a different action for a keycode when the SHIFT or CTRL keys are held down. This would require significant changes to your KeyMapper class, but only a simple change to the guard function is required.

]]>
By: Bjorn Schultheiss http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/comment-page-1/#comment-6208 Bjorn Schultheiss Sun, 13 Apr 2008 13:45:30 +0000 http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/#comment-6208 <p>The only time this seems useful is if your repeating the same 'if statement' in multiple methods, otherwise you've simply wrapped the if statement in another function...</p> <p>I was interested to see how you were going to modify sendButton.addEventListener(MouseEvent.CLICK, onSendButtonClicked);</p> <p>but later you replaced it with sendButton.addEventListener(MouseEvent.CLICK, onSendForm);</p> <p>ahh well.</p> The only time this seems useful is if your repeating the same ‘if statement’ in multiple methods, otherwise you’ve simply wrapped the if statement in another function…

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.

]]>
By: Functional ActionScript – Part III — RTFM / Daniel Gasienica http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/comment-page-1/#comment-5889 Functional ActionScript – Part III — RTFM / Daniel Gasienica Wed, 02 Apr 2008 01:03:59 +0000 http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/#comment-5889 <p>[...] Iconara: Separating event handling from event filtering [...]</p> [...] Iconara: Separating event handling from event filtering [...]

]]>
By: Theo http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/comment-page-1/#comment-5831 Theo Mon, 31 Mar 2008 11:44:53 +0000 http://blog.iconara.net/2008/03/30/separating-event-handling-from-event-filtering/#comment-5831 <p>Stephan: yes, I agree, your solution is quite elegant. I have nothing against the if-statement in your handleKeyEvent, it is not of the kind that makes code fragile.</p> <p>guards are very general and there are absolutely better ways to solve specific cases.</p> Stephan: yes, I agree, your solution is quite elegant. I have nothing against the if-statement in your handleKeyEvent, it is not of the kind that makes code fragile.

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

]]>