|Written by Ian Elliot|
|Friday, 18 November 2011|
Page 1 of 2
It is one of the few mainstream languages that doesn't simply mimic the C/C++ way of doing things. It is also quite different in terms of its treatment of objects. The problem here is that programmers tend not to spend the time to find out what these differences are. They simply notice that it doesn't have "class" and it doesn't seem to have inheritance and then they spend lots of time inventing ways to add them or, worse they propose an upgrade to the language that adds them.
First off it isn't clear that "class" is the best way to work with objects, and it certainly isn't clear that class-based inheritance is even good, let alone the best.
The argument goes that in a strongly typed, class-based, langauge you can't assign apples to oranges because they are different types. This is fine, but the real question is why any programmer would make the mistake of assinging apples to oranges; and what is it about the way apples behave that make this even thinkable. Is it that perhaps apples have a method in common with oranges that suggest that they can be used in the same way? In which case perhaps the language should make an attempt to work out what the programmer intended rather than just flagging a type error.
I'm not saying that either approach is always correct, just that the answer isn't as clear cut as you might expect.
Introducing strongly typed objects creates a new class of errors.
If you don't believe me just check out the reaction of a beginner when told that they can't do something like:
because 1 is an integer and not a string. Yes this is all true but how brainless the compiler is that it doesn't know how to do the conversion.
So the points at issue are:
Lets see how all this works.
If you want to create lots of instances then you need to write a function (which is an object) to create another object. That is you create a function which spits out the object you really want to create.
Notice that if you have dynamic objects in a language then you don't need to worry about the object's type and hence you don't need to worry about inheritance. Inheritance is the classical way of extending the type system. You start off with a base type, usually Object, and you increase the number of types by inheritance. The result is a type hierarchy and a set of complicated rules that govern what types can be used where - subclassing, up casting, down casting, covariance, contravariance etc.. And then to make everything more powerful you invent generics which allow you to write algorithms that are type independent.
Inheritance and strong typing go together.
Don't misunderstand my meaning. Strongly typed object-oriented languages are great, but they are not the only way of doing the job and they are not provably the best way.
|Last Updated ( Friday, 18 November 2011 )|