How To Use .call(), .apply() and .bind() In Javascript

Back in March I wrote a post "Understanding Constructor Functions in Javascript and This keyword" in which, while explaining the concept of this in Javascript, I stated that it is impossible to tell what the this keyword references by just looking at the function definition. You only get to decide or know what the this keyword refers to, by the way the function is called. Call the function one way, and have this refer to one object, call it another way and you can have it refer to a totally different object. Showing that in Javascript, this is a context-indicator.

I mentioned that normal calling of a function (i.e. have a function fx, call it via fx()) and calling with the new keyword i.e. (new fx()) are some of the various ways to call a Javascript function and have the this keyword switch context.

There are 3 other ways a Javascript function can be called with the ability to determine what this keyword references. call, apply and bind. To be technically specific: Function.prototype.call, Function.prototype.apply, and Function.prototype.bind.

Javascript is not Java. Deal with it

There are different paradigms when it comes to programming languages. With each paradigm, you have different and unique methods and concepts that are used in the task of computation and getting the computer to do what you want. Sometimes these concepts share similarities; sometimes they go about their task in totally different ways. The merit of a paradigm is thus judged against the backdrop of the problem it is being used to solve and whether it is the best fit.

It would then be totally silly and dense to put a language down solely on the fact that it incorporates a different paradigm when compared to a language you are familiar with. Most of the bashing I see targeted at Javascript is largely due to this: coming from a different programming paradigm and getting miffed when different ways of doing things are encountered in the Javascript land.

At the risk of being wrong and committing fallacy of hasty generalization, I would say Java developers are most guilty of this (maybe it has to do with the misleading "Java" in Javascript? :p)

I say this, because from personal experience, (which I know is limited) I do not get the same close mindedness from the Python, Ruby and C# devs that I know.(This explains the title of the post I guess :p)

Maybe it is that difficult to come to terms that Javascript is a prototype based object oriented language and not a class based language?

Consequences of this close mindedness towards Javascript, thus lead to hacks and practices that try to bend and mould Javascript into something which it is not. I most of the time find this to be quite uneducated.

Coming from a Javascript-first background, before Java, I guess made it quite hard for me to have this kind of narrow mindedness and priggish attitude? I guess this helps to easily appreciate the unique ways of doing things in both languages. I like to think that this makes a better developer, as it is quite interesting to see how different ideas are implemented across languages and borrow from them in situation, when it is germane.

So when (if) I want to learn Haskell, I won’t go about complaining over how it has so many concepts; tricky and odd concepts and how it does things different when compared to say Javascript. And I wont try to write Javascript in Haskell.

And by the way, Javascript is not the only language that has its good parts. Every language does, Java, C++ inclusive :)

Fixing org.springframework.http.converter.HttpMessageNotWritableException Error

A couple of days back, I ran into an interesting error while retrieving persisted entities as JSON  in SpringMVC:

[Request processing failed; nested exception is org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: Infinite recursion (StackOverflowError)...

I had to do some poking around and reading up on documentation to figure out how to fix it.

As it turned out, the fix wasn't that complex and the culprit was Jackson: the Java-JSON processor being used to transform the retrieved Java entity to a JSON representation.

The error occurs when you try to retrieve an entity that has a bi-directional @OneToMany relationship with another entity.

Enum in Java.

Let us assume you have the need for some constants in your application; say the three primary colors: Red, Green, Blue. You could create a class specifically for holding the constants thus:

class PrimaryColorsStatic {
        public static final String RED = "red";
        public static final String GREEN = "green";
        public static final String BLUE = "blue";
}

and any of these can be used: PrimaryColorsStatic.RED or PrimaryColorsStatic.GREEN or PrimaryColorsStatic.BLUE

This would work, but it is very limited. Let say you want to hold, apart from the name, the hex code and rgb code of the color as part of the constant? How would this be done with the mechanism above? Whatever way you find to implement this would feel forced as static variables of classes were not designed to help fulfil such use cases.

Enum in Java provides a more robust mechanism for dealing with constant values in your application.

Enum can be formally defined as a special data type that enables for a variable to be a set of predefined constants.

The basic syntax is simple. The primary color example can be represented as an Enum with the following code:

public enum PrimaryColorsEnum {
     RED, GREEN, BLUE
}

[this means that the file would be saved as PrimaryColorsEnum.java]

and an example of accessing it would be:

public main void() {
    PrimaryColorsEnum RedHolder = PrimaryColorsEnum.RED;
    System.out.println(RedHolder);
}

This would print red to the console as a string.

Just knowing the above syntax and when to use it could get you by with Enum, but you have hardly scratched the surface with just that.

To fully appreciate Enums, let us take a step back and see if we can grok the concept in a more detailed level.