Questions about 'new' : is this pattern legit?
in [JavaScript]
|
Prev: FAQ Topic - Why does simple decimal arithmetic give strange results? (2010-03-31)
Next: Consolidate Credit Card Debt
From: nick on 1 Apr 2010 22:07 On Apr 1, 4:56 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > On Apr 1, 9:38 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > ... > > Agreed. You could also probably do the following. > > myApp.keys = { > 'w': panNorth, > 's': panSouth, > 'a': panWest, > 'd': panEast > }; > > --Antony It would be something like myApp.keys.callbacks = {...} The problems I have with that approach are: - The keys are indexed as numeric keycodes, not strings. The 'register' function allows user to pass either. - Makes error handling / input cleaning more difficult. - User might inadvertently wipe out the callbacks object when they really just meant to add some stuff to it.
From: Antony Scriven on 1 Apr 2010 22:50 On Apr 2, 3:07 am, nick wrote: > On Apr 1, 4:56 pm, Antony Scriven <adscri...(a)gmail.com> > wrote: > > > myApp.keys = { > > 'w': panNorth, > > 's': panSouth, > > 'a': panWest, > > 'd': panEast > > }; > > It would be something like myApp.keys.callbacks = {...} That's not important; it's just an example. I'm not going to try to second-guess your entire codebase. You'll have to extrapolate from the example yourself. > The problems I have with that approach are: > > - The keys are indexed as numeric keycodes, not strings. > The 'register' function allows user to pass either. Using magic numbers in your code isn't helpful. > - Makes error handling / input cleaning more difficult. How? / huh? > - User might inadvertently wipe out the callbacks object > when they really just meant to add some stuff to it. Then that user shouldn't be writing Javascript. Something else to bear in mind is that if you have references to the functions in an easily accessible object then they can be easily manipulated. E.g. var keys = myApp.keys.callbacks; var oldKeyW = keys.w; keys.w = function(){ doSomethingNew(); oldKeyW(); }; If, on the other hand, you don't want the functions to be easily manipulated then see my first comment. --Antony
From: Garrett Smith on 2 Apr 2010 00:15 Thomas 'PointedEars' Lahn wrote: > johnwlockwood wrote: > >> Thomas 'PointedEars' Lahn wrote: >>>> var alert; >>> You don't want to do that. >> Ok, the only reason I did is jslint.com gave the error "Implied >> global: alert" > > You probably get the error because you called > > alert(...); > > not because you have not declared it. Call > > window.alert(...); > > and take everything jslint says with a handful of salt. > s/handful/bucket. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: nick on 2 Apr 2010 02:49 On Apr 1, 10:50 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > On Apr 2, 3:07 am, nick wrote: > ... > > It would be something like myApp.keys.callbacks = {...} > > That's not important; it's just an example. I'm not going to > try to second-guess your entire codebase. You'll have to > extrapolate from the example yourself. Whoa, easy there. I only pointed that out to avoid confusion. > > The problems I have with that approach are: > > > > - The keys are indexed as numeric keycodes, not strings. > > The 'register' function allows user to pass either. > > Using magic numbers in your code isn't helpful. I'm not using 'magic numbers.' Either the argument is a number, and it is interpreted as a keycode, or it is a string, and it is interpreted as a character representation of a key, or it is something else and it is ignored (for now). > > - Makes error handling / input cleaning more difficult. > > How? / huh? Because the user sets a property of an object directly instead of calling a function to alter an internal object. Intermediate stuff can be done in the function before altering the object. The difference should be obvious. > > - User might inadvertently wipe out the callbacks object > > when they really just meant to add some stuff to it. > > Then that user shouldn't be writing Javascript. in before 'or javascript' ^ > Something else to bear in mind is that if you have > references to the functions in an easily accessible object > then they can be easily manipulated. E.g. > > var keys = myApp.keys.callbacks; > var oldKeyW = keys.w; > keys.w = function(){ > doSomethingNew(); > oldKeyW(); > }; Right, except it's not .w, it's [87], because it's indexed by the char code (so all key events can be trapped, eg bksp, f5). There's a function keys.list() that will return the callbacks object if the user really wants to manipulate it directly. Or, you could call keys.list('w') and it will return callbacks[87] for you. > If, on the other hand, you don't want the functions to be > easily manipulated then see my first comment. --Antony Functions? Not sure what you mean by that.
From: Antony Scriven on 2 Apr 2010 05:32
On Apr 2, 7:49 am, nick wrote: > On Apr 1, 10:50 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > > > On Apr 2, 3:07 am, nick wrote: > > ... > > > It would be something like myApp.keys.callbacks = {...} > > > That's not important; it's just an example. I'm not > > going to try to second-guess your entire codebase. > > You'll have to extrapolate from the example yourself. > > Whoa, easy there. I only pointed that out to avoid > confusion. I made the remark because I sensed you were dwelling on details rather than concepts. I didn't mean it harshly. > > > The problems I have with that approach are: > > > > > > - The keys are indexed as numeric keycodes, not strings. > > > The 'register' function allows user to pass either. > > > Using magic numbers in your code isn't helpful. > > I'm not using 'magic numbers.' Either the argument is > a number, and it is interpreted as a keycode, or it is > a string, and it is interpreted as a character > representation of a key, or it is something else and it > is ignored (for now). Why use 107 when you can use 'k'? (Or whatever the code is.) I'm not saying you shouldn't use numbers, just that there appears to be no obvious reason to do so given the code you've presented so far. If you're dead set on implementing it your way then just snip this paragraph in your reply. > > > - Makes error handling / input cleaning more > > > difficult. > > > How? / huh? > > Because the user sets a property of an object directly > instead of calling a function to alter an internal > object. Intermediate stuff can be done in the function > [the function that register the keypress handlers] before > altering the object [that stores the handlers]. The > difference should be obvious. Well of course. But I don't see how that applies to error handling. And I've no idea what you mean by `input cleaning'. > > > - User might inadvertently wipe out the callbacks > > > object when they really just meant to add some stuff > > > to it. > > > Then that user shouldn't be writing Javascript. > > in before 'or javascript' That doesn't make sense, sorry. > > Something else to bear in mind is that if you have > > references to the functions in an easily accessible > > object then they can be easily manipulated. E.g. > > > var keys = myApp.keys.callbacks; > > var oldKeyW = keys.w; > > keys.w = function(){ > > doSomethingNew(); > > oldKeyW(); > > }; > > Right, except it's not .w, it's [87], because it's > indexed by the char code (so all key events can be > trapped, eg bksp, f5). Again, that is not the issue; this is just an example. Change the `.w' to `[87]' if you want, it's completely beside the point. > There's a function keys.list() that will return the > callbacks object if the user really wants to manipulate > it directly. Or, you could call keys.list('w') and it > will return callbacks[87] for you. So then when you change a callback (to use your teminology) you're bypassing your register() function? > > If, on the other hand, you don't want the functions to > > be easily manipulated then see my first comment. > > Functions? Not sure what you mean by that. One of these: function(){} :-) The term callback doesn't make a lot of sense in Javascript if you ask me, and it's not one I've heard used with reference to Javascript before. Maybe the term `event handler' would be more natural. --Antony |