This whole thing started out as a nice-to-have. I have a blog (you’re reading it). I have a URL shortener (jmbk.nl). They are separate apps on separate domains. When I publish a post here, I diligently create the short URL for it manually in order to publish that short URL on social sites (the URL shortener has some minimalist stats associated with each short URL; so minimal, it’s only a count of the number of times it was used). Yeah, I know, silly, huh: why can’t each post generate its own short...
Read more »
I was reading some JavaScript code the other day, because, you know, reading someone else’s code gives you insights and inspirations to improve your own, when I came across this function to calculate the maximum element in an array: function max(a) { for ( var i = a.length, maxValue = a[0]; i--; ) { a[i] > maxValue && (maxValue = a[i]); } return maxValue; } Taking it slowly, first of all, check out the for loop. For comparison, here’s how I’d write it myself: var maxValue = a[0]; for ...
Read more »
There’s a concept in functional programming called currying which gives you the ability to create one function from another, and have the created function call the original but with some arguments prefilled in. To be ultra-rigorous, we assume the original function has n arguments, and currying produces a chain of n functions each taking one argument to produce the same results as the original. We, however, will skip that rigorous definition since it’s too constricting for our discussion here. Instead ...
Read more »
In C#, we have implicit and explicit conversions. In both cases the idea is that we, the readers of the code, are not surprised by any conversions that happen. That’s why we can freely intermix int s with float s in a floating point calculation and everything turns out just fine. The int s are implicitly converted to float s (there’s no data loss) and the calculation comes out right. However, when there’s a possibility of some kind of data loss (say, converting a ulong to a long variable) you have...
Read more »
(For background, please check out parts 1 , 2 , and 3 before reading this post.) One of the problems about private local variables inside closures is that you can’t see them. Well, duh, you might say, that’s what private means after all. Point taken, but there’s one scenario where it would be really nice to be able to check those enclosed (enclosured?) variables: debugging. Now, I’m not going to get into the whole argument here about debugging versus testing. I’m of the firm belief that you should...
Read more »
Way back in March 2009, I wrote a quick post about the JavaScript arguments quasi-array , about how the interpreter sets it up on every call to every function to hold the arguments passed to that function. Although I blithely talked about the fact that arguments was array-like , it wasn’t a real array (it’s not typeof Array ) and didn’t have methods like pop() and the like. In fact, it only really has a length property and a bunch of properties named ‘0’, ‘1’, ‘2’ and so on. So it’s easy to iterate...
Read more »
Now that we’ve seen the simple module pattern as well as ways to augment it , we should take a look at one final piece of the puzzle. Private fields, as we saw in the last installment, can be a real issue. Sometimes, dammit, we’d just like to refer to that private local variable when we’re augmenting a module object. Just a peek you understand, and we’d make it private again immediately we’re done augmenting, so that the code using the module object doesn’t see this private variable. Unfortunately...
Read more »
Last time I talked about the simple module pattern . This is where you create a function that returns an object with behavior and state and that behavior and state is implemented (and made private) by using a closure. We showed this by using the module pattern to create a stopwatch object. Let’s now see how we can extend this stopwatch object by adding the facility to have lap times. This gives us the ability to use the same stopwatch to time a sequence of time-consuming actions, rather than creating...
Read more »
If you recall, JavaScript closures are an extremely powerful concept in the language. By using JavaScript’s rather peculiar scoping rules, closures are a way of creating private variables and functionality for an object. The module pattern builds upon this feature. A quick recap on scope in JavaScript may be in order. Scope is the means by which programmers limit the visibility and the lifetime of their variables and parameters. Without scope, all variables would be global and visible everywhere...
Read more »
I can’t believe that I haven’t posted an article on how to call functions in JavaScript and what this gets set to for each of the various invocation patterns. It’s one of those things that catches people out periodically, so it’s well worth discussing at length. There are four different ways to call or invoke a JavaScript function: method invocation , function invocation , constructor invocation , and apply invocation . Each of these invocation patterns results in this being set to a different object...
Read more »
