Class, type and interface
How should a new object be built? the constructor
The concept of heritage allows an object to dispose of the slots of another object. The inheritance-concept being supported by the “prototype”-object associated to the newly-created object (this works sort of like in a chained list) where the executing motor searches for unknown slots by reviewing a list of “ancestors” from the bottom.
Contract, classification and typing
How should an object be “classified” and how to be assured that an object belongs to a given type and so answers to an interface? Behind all this I believe sits the question of the behavior – “how is this object going to react faced with this message?” – in application of the substitution principle developed by Barbara Liskov.
My ideal language? One based on prototypes, strongly typed and dynamic
In an ideal world I would like a language based on prototypes, strongly typed and dynamic. What is important to me is:
- How do I build an object and how do I define its attributes and the functions linked to its changing states?
- What is the contract of this object and how can I assure the correct use of it? possibly before code execution
Python is one of the closest language from that ideal, but I find the new kids on the block (Dart, Contracts.Coffee inspired by Racket, etc.) to be smart enough to gently allowing introducing strong typing when one has the most need of that feature.
Update the Feb 10 :
This discussion about « untyped » on Stack Overflow give a lot of clues about that subject.