Page 1 of 2
Now available as a book from your local Amazon.
The Amazing Parts
- Jem 2 The Inheritance Tax
- Jem 3 Functions Are Objects
- Jem 4 Objects, Functions And this
- Jem 5 Every Object Is An Anonymous Singleton
- Jem 6 Objects Have Value
- Jem 7 Numbers And Other Values
- Jem 8 Truthy And Falsey
- Jem 9 The Comma
- Jem 10 Code As Data
- Jem 11 Lambda expressions ***NEW!!
- Jem 12 Fluent Interfaces
- Jem 13 Hoisting, Scope And Lifetime
- Jem 14 Amazing Async
- Jem 15 The Revealing Constructor Pattern
- Jem 16 Functional And Not Quite Functional
- Jem 17 Immutability
- Jem 18 Functional Approach To Iteration
Extract 1 Functional Iteration
- Jem 19 Metaprogramming - The Proxy
Extract 1 The Proxy
“Better a diamond with a flaw than a pebble without.”
Object-Oriented and Dynamic
This is a question that is really only answered by reading the rest of this book, but it is worth a summary.
In traditional object-oriented languages, objects are created by first defining a class, i.e a blueprint for an object. Then you create an instance of the class, i.e. an object. This is not a bad way to work with static objects and it fits in well with strong static typing, which is an approach many programmers think is good.
Of course, there are many who judge this particular jem to be a dud. Most disciplines of object-oriented programming insist on strong typing where objects are defined by classes which cannot change dynamically. Classes can inherit from other classes and this leads to a type hierarchy.
In theory, type checking using this hierarchy can find many errors, but all the errors that it finds are fairly easy to find at compile time and the approach is still subject to runtime-type errors. The consensus is that this approach to objects is more robust, but it can be argued that it simply introduces another level of complexity without delivering any important advantages.
This is not a widely held point of view and many programmers will swear that strong typing has saved them on more than one occasion and doing without it would be difficult. The problem is that this is a comparison of finding an error with perhaps not-finding the error and in truth the error wasn't that hard to spot, with or without strong typing. You used the wrong object, property or method.
There is also the claim that strong typing makes big projects easier to handle. This is often true, but only when typing is used as an alternative to good documentation and programming standards.