The Value Of Strong Typing - Generics

If you are familiar with a strongly typed language then you will recount many occasions when it has picked up an error at compile time that you might have missed until runtime. This is undoubtedly true - it happens all the time.

However remember that what it means is that you have used the wrong object. 

For every time you are saved from an error by type you will probably have had to do some complicated dance to get around the problem that the object you have is the wrong type. In general you find that you can't just do what you want even if you know the type of the object.  In particular you often can't call a method that you know that the object has just because it is currently referenced by a variable of the wrong type. 

You can decide that these benefits are worth the extra fiddle of having to cast to other types and risk runtime errors. Many programmers do and couldn't imagine a life without strong typing.

However strong typing also means that you cannot write generic algorithms. A generic algorithm is one that applies to a wide range of object types. For example, you might implement a sort algorithm that can sort any objects no matter what as long as you can supply a comparison function.

There are two general ways of creating a generic method 

The first is that you can use the root of the type hierarchy, usually Object, to create variables that can reference any object type.

In most languages a variable of type Object can reference any other type in the type hierarchy - as they are all sub-types of Object. In this sense Object acts as a completely general "untyped" reference. Except, of course, as the declared type is Object you can't access any methods or properties of most of the objects it references unless you use a cast. So it isn't quite as powerful as an untyped reference. 

This has the advantage of simplicity, but now you have really given up on strong typing and are using Object as a general catch-all type. You also have to rely on casting to get your data back into its real type before you can continue to use it.

The alternative is that you can use the language's generic typing facilities - if it has any. This essentially allows you to specify type as additional parameters.

Consider:

T add <T>(T a,T b){return a+b};

where <T> is a parameter that specifies the type of the object being used. When you use the generic method you have to specify the value of the type parameter.

For example:

int c=add<int>(1,2);

uses the generic method with T set to int. 

Of the two methods generics is better because it type checks the method in the form in which you are using it. However, it is more complicated and it also has its limitations in most implementations. 

Of course if you drop typing then every function you write can be generic.

In fact things switch around in this case and the problem becomes not making functions work with a wide range of objects, but restricting the range that they work with. More of this idea in the next chapter.

The Value Of Strong Typing - Inheritance

Then there is the small fact that strong typing depends on the inheritance hierarchy.

The hierarchy of types that you use is exactly the same as the class hierarchy created by inheritance. Many programmers think that inheritance isn't the best way to go and we often hear "prefer composition to inheritance".

What does this mean for the value of hierarchical typing?

There are also a number of ways of trying to patch up the problems of class based inheritance. The most common is the idea of an interface - which is sort of like a class without any implementation details. In this scheme  of things a class can inherit from another class complete with an implementation of all properties and methods and/or from an interface when it has to supply the implementation. 

Interfaces are supposed to be safer and more stable because you code the implementation rather than just accepting a base implementation. However it more or less does away with any code-reuse that inheritance offers. In fact when you work with interfaces you are returned to the days of copy-and-paste reuse and we all know how that doesn't work. 

JavaScript doesn't have inheritance and it doesn't have interfaces.

It does have the ability to compose objects and it has a way to allow code reuse via the prototype. How this works will be explained in the next chapter. 

The Final Word

There are arguments that strong typing creates a discipline of code that makes errors less likely and this is true. Any discipline in coding probably produces better code. In most cases there is no harm in adopting a strong typing approach apart from the fact that it makes some more sophisticated tasks more difficult than they need to be.

You can argue that most of the code we write isn't this difficult. You can also argue that most programmers don't create huge class libraries and therefore many of the issues of inheritance are irrelevant. This is also true. 

What is important to realize is that strong typing based on a hierarchical type system serves just one purpose - to check at compile time that an object you are using has the properties you are using. 

Strong typing is like a straight-jacket - it keeps you sane by restricting what you can do. 

The real problem here is that this is not always possible and when it isn't possible you have to resort to other approaches.  

In a language that is not strongly typed it is still often possible to work out if a method call or property access is valid by just looking to see if the object used supports it - this is often called type inference but only because the world is obsessed with the idea of type. 

When this cannot be determined at compile time then the dynamic language has to resort to the same approaches as the strongly typed language. 

In the next chapter we find out how to live without type in JavaScript. 

Summary 

There really are only two ideas in this chapter but ones that are difficult to explain and difficult to make clear in today's environment.

• Primitive data types are about how data is stored and this is only about efficiency.
  
  
• Differences in data are all represented in the operators and methods that can be applied to them.
  
  
• Class based hierarchical type checking, in fact all type checking is about answering the question - does this object support this property/method - at compile time. 
  
  
• Even with strong typing it isn't always possible to determine the answer at compile time. 

Just JavaScript 

 There is a newer version of the draft of the book here.

A Radical Look At JavaScript

Contents

1. JavaScript Isn't Java, or C, or C# ... (Book Only)
2. In The Beginning Was The Object
3. The Function Object
4. How Functions Become Methods
5. The Object Expression
6. Object Construction
7. The Prototype
8. Type And Non-Type
9. Constructor And InstanceOf
10. Duck Testing And Prototype Construction

-Preface-

Most books on JavaScript either compare it to the better known class based languages such as Java or C++ and even go on to show you how to make it look like the one of these.

Just JavaScript is an experiment in telling JavaScript's story "just as it is" without trying to apologise for its lack of class or some other feature. The broad features of the story are very clear but some of the small details may need working out along the way - hence the use of the term "experiment". Read on, but don't assume that you are just reading an account of Java, C++ or C# translated to JavaScript - you need to think about things in a new way. 

Just JavaScript is a radical look at the language without apologies. 

Related Articles

Late Binding - Myths and Reality

Just JavaScript - The Object Expression       

Covariance And Contravariance - A Simple Guide       

The Working Programmer's Guide To Language Paradigms       

Data Typing Is A Relic       

Strong Typing       

Weakly Typed Languages    

Type Systems Demystified         

Casting – the escape from strong typing       

To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin,  or sign up for our weekly newsletter.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info

<ASIN:0596805527>

<ASIN:193398869X>

<ASIN:0137054890>

<ASIN:1449381871>

<ASIN:1430230541>