DEV Community: went

Dead Simple type checker for JavaScript

went — Thu, 19 Mar 2020 19:26:43 +0000

Type Checking in JavaScript is very complicated for beginners. There are only Data Types. And everything the rest is something very different from well known and common used meaning of Types. We might be having null or undefined or something derived from Object or other constructors. And any derived from Object is not a Type, but Structures. And this might seem very opinionated and dependent from JavaScript Engine, but undefined has it's own Constructor, and when we make "void 0" will invoke that constructor for new memory pointer marked as undefined data. Therefore there is a lot of misunderstanding and misconceptions for those are new with JavaScript world. Sometimes it even harder for developers used to study with Strict Typing Systems in mind, but anyway, there are many pitfalls in general.

Concept

Each constructed structure has instance.constructor.name, where instance is a pointer to our variable and .constructor.name is obligatory path, pointing us to the name of constructor invoked during instance creation. Therefore all non primitive so-called "types" has .constructor.name. And what is "non primitive" then? Eh... non Data Types, but something else. And Data Types is that sort of thing which marks memory allocation as a type: data Primitives:

undefined
Boolean
String
Number
Symbol
BigInt

and not so about data, but primitive of everything wich we discuss more in a moment below:

null

And isn't it true that all these have constructors? Indeed, they do. But wich sort of constructor do they have? There is a bit difference: constructors for primitives do memory allocations for Data, and they then answers the question "which data type is that allocated memory".

It is not so special, but it is different from everything the rest in JavaScript: when other constructors are for Structures, not for Data.

And there is one very special thing: superheroic null, which allows us to have all the other constructors. And din't null has own constructor itself? As it is the only SuperDuperPuperClass, and Singleton we might say yes and no, simultaneously. And it is the only thing the other thing are derived from. It is so special and the same place so simple: but nobody cares of it, we just used to hate typeof null === 'object' and that is it. But instead of doing this, please just look for the whole system. It is simple, straight, and it might be said: "it is Full".

Again: there are only Data Types and Structures soo what is the Next Step? Yes, there is a next step. And this step is instanceof. When we construct something, we might be willing to check if we did construction from exactly that constructor in future. And this points us to the next big question in JavaScript: Inheritance. It might be the other even greater complicated topic, no matter how many times you've read about it. And from the other side there are not so many developers who was able to explain this topic well in each aspect. Remembering the early dates when there was a war between Netstcape Navigator and Internet Explorer 3~4 even I did two novelistic memoirs, please forgive me suggesting it:

Romantic, with only one example: Architecture of Prototype Inheritance in JavaScript
Nostalgic, with a lot of memories behind, few examples: Inheritance in JavaScript : Factory of Constructors with Prototype Chain : point of view from boring nerd

Starting from this is a moment I have to say sorry again, because now I will think we can share the same meanings.

Therefore we might succeed everything constructed has an instance.consructor.name. But as we saw there is another big thing for Constructed: where constructible function meet Prototype being invoked with new keyword. And we can rely on it, safely. The only exclusion is Object.create, but even then, there was construction derived from prototype, though constructor was Object itself. And we might be saying that {} or [] have not yet being constructed? But there is no other way to simplify this process, so it was just lexer helping us with AST making special notes for messing up [] with new Array and {} with new Object. And even deeper, as Arrays are derived from Objects, so by the typeof checker Arrays are Objects. This is done that way because typeof just checks Data Types (primitives), and Array is not Data Type, it is a special Structure of the other things. That is why it is an 'object' for typeof checker.

Being realistic we can see it is done that way for more than 20 years ago. And it is useless and pointless to think the other way for practical usage, despite we wish the "better". And we might don't like this, but there is true beauty when we accept and understand it instead of hating. It is very useful and very simple when we can rely it without breaking it. And this more than scalable and there are no good points for making it better. "This" system is Full, it is not necessary to extend it with something else.

As we then see: everything constructed (and derived from null) returns 'object' as a result of typeof checking. And the special case null returns object too, because it points to the .constructor.name and constructor of null is Object, the only thing being singleton null has no properties. But truth is the following: thinking of data type checking there are no tasks of checking .constructor.name from null.

Keeping all this in mind we might build very simple system. Just being aware of the thing that does yet not implemented, this short sequence of conditional logic:

get the typeof of provided instance;
if this is not an 'object', then it is a primitive, and we might return the answer right now;
if it is null return null;
if .consructor.name returns object, then it is structure, derived strictly from Object constructor, no matter how;
if .consructor.name returns something from primitive constructors, 'String' or 'Number' or .., then the answer is that .name, for better compatibility let .toLowerCase() it;
if .consructor.name is 'Array', 'Date', 'Map', 'WeakMap', 'Set', 'WeakSet' we might again .toLowerCase() the answer, because mostly this structures are used for storing Data;
I'd personally suggest 'RegExp' and 'Promise' as something very tightly coupled with data, but this is my choice, judge me an Issue;
And yes, there are many types for Errors, and each one of them derives Error, so this is just an 'error';
The last thing is 'Function', and just because this is a very special case, there is a simple answer, we will use direct answer from typeof received at 1.;

All the other types we might be willing to have in this "type checker" for our new shiny Type System will receive .constructor.name as an automated Profit! It is not necessary to check them deeper. If we will wish we might rely on Object.getPrototypeOf(instance.constructor.name), and we might use underground names of constructors. If we will need it later, we might use instanceof. But we should rely on our personal feelings about the other modules of our codebase because of the very broken thing comes with Object.create's dawn in JavaScript ;^):

        function foo() {}
        var bar = { a: ‘a’};
        foo.prototype = bar; // Object {a: "a"}
        baz = Object.create(bar); // Object {a: "a"}
        baz instanceof foo // true. oops.

Dear Eric, thank you very much for this example. Here is a link of Your wonderful article Common Misconceptions About Inheritance in JavaScript

So we will either avoid using Object.create if we need that checks, or will invent something like hidden Symbol, pointing us to real constructor.

Finally if should we bring very deep Prototype Chain to codebase, for example – Object->Array->Proxy->Object – then we might choose the last .constructor.name as a pointer to the derived type. And for sure we might be willing additional typechecks in that case, but that is not so dead simple.

Pros & Cons

This was an explanation of how everything works. It is small, and we may rely on it for better understanding of JavaScript structures, especially Object's derived structures. And, for sure, if we will use this understanding in a combination with other libraries, which does not provide the same level of abstraction in mind, we might fail. Or from other side we might win with distinguished explanation where they fail.

Architecture of Prototype Inheritance in JavaScript

went — Wed, 18 Mar 2020 00:52:56 +0000

I'm stuck. Yes, I stuck. I did it the first once, then second, third and finally just ... stuck. It blows my mind, though, I think this should be coded somehow, yes. It might be the general purpose library or command line interface, whatever. It might combine the way of usage. And it is about how we code algorythms, for sure we shall live with it.

For the vista of re-vision let assume it is a secret that Algorithm is a "sequence" ... of of well-defined, computer-implementable instructions ... and so on ...

And there is Topological sorting and all the way we do instructions is a pipline of data processing.

And what if there is a thing we might avoid thinking of as of a sequence? Undoubtedly from well known Black hole Information Paradox we might probably review our understanding of "everything" as a "sequence". But from the other side there is Poincaré conjecture and there is an impact to the solutions where we should throw out the Ideas with broken Topology.

In an attempt to prepare us for the next step here is other nice beginner's topic: Composition over Inheritance, and here is same title video from Fun Fun Functions.

And the hidden question there:
Is Composition a Sequence or Not?

Well... we might obviously converse it is a technique to combine reusable sequence part of algorithms to make them work more efficiently in a whole structure.

« But it's not that easy when your soul is torn in two »

I mean, reusable parts is a great idea, all that stuff which reusably Controls the flow of our code: Loops, or Recursions or... nevermind, they are made for Greater Good. Generators with Promises and all that async'ish stuff are great helpers.

Though when we will climb up and down on the "ladder of abstraction" probably we will see the whole thing, but there might be hidden "black hole's event horisons" which we will probably hardly overcome with thinking of code "reusability".

I mean "reusability" is not a thing, but "sequence" is a Thing, very natural thing with a lot of characteristics, for example "State" or "Observability" and "Measurements". And all this sequenced async stuff is done narrowing calculations with raw data or even with well prepared Information or odd it might be "of the bit" eventually just feelings of the kinds.

Then well, when we shall connect that feelings of our mind with sequence, can we get the idea of beauty? Shold we reuse it? Or should we repeat it recursively for whatever this might be meaning then?

I don't even understand what I'm writing, this might be complete noise, or one of the definitions of "42". And indeed it is proven by Gödel's incompleteness theorems.

And 42 itself is a serial number of multiplier symbol of ASCI symbols table, which is then connected to "...ad Astra" in Latin, and then to Astarte or Ishtar, the godess of love,
power and war from the Bronze Age. And she is then an avatar of Shakti or Pravati in Hinduism.

And here we might think Cosmos and topology and time are connected to algorythms and lifecycle of data.

And what if we can combine all this flavors to a Chain of responsibility with declarative Meta-programming?

This definetely might be coded...
We indeed can craft code allowing us to aid information retention during data lifecycle... But the question is still there: what is a Sequence?

What is of that piece of minimal abstraction we should re-use avoiding of Entropy? Where information retention is not so enough? And should that hidden piece be sacred or not?

Describing algorythm as a Narrative story and Plot we might convince then the aspect of chronological order of the events in the meaning of Chronotope is very tightly coupled with the concept of Grammatical modifier in the meaning of Function composition and Object composition at the sequence of time.

And the concept of Modifier in Software Engineering describes exactly what we are seeking for. There is a lot of them, here are just a few of may other examples:

for Access: Private, Static, Protected, Internal ...
for Type: Signed, Unsigned, Short, Long ...
Behaviour: 'use strict';, "... throws" to be "thrown"

And each one of them describes an answer to the question "what will happen": so, this is a setting for Chronotope. Despite of Type Systems answering the question "what is it", modifiers answers the questions "how are they". So shouldn't then there be the a question "when they are", and "why they are" and even "whose are they" in Runtime?

For sure, the answers are "Yes" for all that questions, it is just what we are doing as a developers. Crafting our algorythms we describe the answers to that questions, we always make:

extracting or consuming data,
transforming data from one form to the other,
and then we might be storing the data or loading it somewhere else.

And seems nothing is wrong here, but... why then we have a lot of bugs everyday, isn't this is a point we might be missing something? Seems there might be some hidden review point and we shall find it for the Greater Good in a memory of the past.

Indeed, then here I stuck seeking for solution.

And then I remembered... It was far ago, more than 20 years, as if should it be me getting back to the past as mystic re-vision of my own future. And I got it just few month ago, obviously by a chance. To be honest it was not me who found it. I just felt it is what am I seeking for. And even more, I felt it only now, passing 20 years of seeking for nothing, being able to touch it anywhen. I can't remember that day well, it was a moment of summer obligatory computer classes after my first University term. There was a file leaved by somewone else on my clasroom's desktop with MS Windows NT. And I do remember when I saw that code I felt like complete dumb. I was unable to get the idea then, though it was clear enough, and I can describe it very well even now. There was Factory function, which was making a function and then that function returned to the variable was constructed, something like this:

    // to the glory of Mnemosyne
    function Factory (previous) {
      function MyConstructor (state) {
        this.state = state;
      };
      MyConstructor.prototype = previous;
      return MyConstructor;
    };

    var initial = { state: 1 };
    var Constructor_1 = Factory(initial);
    var next1 = new Constructor_1(2);
    var Constructor_2 = Factory(next1);
    var next2 = new Constructor_2(3);

What have I missed was the prototype keyword and the meaning what it was doing. There was no debugging tools that times, and I was able to understand the final .state is 3 but it was hidden from me that all previous states are there, inside of Prototype Chain of next1 and next2:

And inspite I noticed the name of Mnemosyne, cause it was very close to Mnemonic and I knew this word from books of tricks and magic, I was unable to connect it with algorythm itself, thinking it was just a joke for some naughty girl.

Having very few competence, undoubtedly I thought the code is just garbage, but it was indeed Genius Masterpiece...

Inheritance in JavaScript : Factory of Constructors with Prototype Chain : point of view from boring nerd

went — Tue, 25 Feb 2020 09:13:23 +0000

Hello fellow Stranger!

This story is about one very special part of JavaScript, the most usable artificial language in the world for now (2019).

IMO no doubt Brendan Eich, the author of JavaScript programming language, is an Outstanding Genius! And this is not because he says:

“ Always bet on JavaScript ”

This story is some sort of philosopher sight on Inheritance in JavaScript and my hope this vision might be based on the most relevant source of knowledge: Life itself, in it’s creatures and creations. I don’t know if it was source of vision for JavaScript Prototype Chain, though if so, this means is so impacting, so strong for me, that… it is hard to even breath…

Let start and our first point is where we Switch On our Imagination and try to get rid of all circumstances, prepositions and other irrelative side-effects.

We going back to the future of early pre Internet Era of 199x.

Starting from the first Hackers who invented everything we know of software, we then can see this Picture from the past: Netscape Navigator 2 in a war run with Internet Explorer 3. Java is just born and almost all, almost everything of current Internet is not yet invented and then might be re-discovered. Might also be as me you were young enough for that Good Old Times, and you can still remember this terrific feelings of how everything is crafted nearby You.

So, with yous very powerful PC based on Intell Pentium 200 MMX™ inside and 32Mb memory and Windows 3.11 or even Windows 95 is onboard you are looking forward. And you also have both of that Web Browsers installed. Dial-Up modem allows you to connect to the Global Network for grabbing some new data, learning, chatting and so on. However stop, no chatting throught web-pages yet, because JavaScript is still not made. Probably you use some delayed messaging systems, might be based on EMail or UseNet or even something like realtime communication technics with IRC.

Couple of years gone, and Everything changed… Now you can see animations of snowflakes on web-pages, celebrating Christmas or New Year. And you wonder how it was done, and you able to find there is a new technology inside, called JavaScript language. HTML is not so new for you, and you start learning that awesome and sparkling tech. Also somehow you then discover CSS, and this is also important, cause indeed everything is done through combining three of them together.

Wow.

And you also might see some wonderful changes for your Windows, you can now create your first application using CScript or even HTA (still works).

You start crafting your first Web Server, using Perl, or C~C++, might be even some bash scripting if you start using Unix-like OS. And everything is bound between with Common Gateway Interface (not that another CGI). PHP is almost not exists yet, and you will probably like it then.

200x Era. You can now use JScript on server with ASP. It looks like very similar to JavaScript you use for your web pages. It is so great. You think of your own template engine, some sort of XML. And then someone named as AJAX all that Dynamic Content Loading techniques you’ve been using for years before. And they do only XMLHTTPRequest for everything, wile you can still think of BMP, iframe, or even <script> tag. And then someone hinted about JSON and how it very pleasant to use it, but you were using it for ages in from of:

        document.write("<" + "script src=" + path + ">");

It is all not that matter now, but you still can remember how…

Then from time to time you might been working with Rhino and Nashorn in an attempt to enjoy your Java customers who use Alfresco or Asterisk. You’ve heard about upcoming JS implementations on hardware chips and wonder what would it be. Also now there is jQuery and Backbone.

Then you are looking on a winter snow of upcoming 2010, and now you know there is a Game Changer number One: Node.js ®. Next ten years you will play with this new toy, and here in 2019 you still can’t believe how great is it.

In general you are enjoying all of that and toys and playing games with them is a great part of your life interests.

But there is one small question, you ask yourself from day to day, from night to night for more than two decades:

How will you explain Empathy in JavaScript?

You know one of the hardest topics about JavaScript is of it’s Inheritance system and Prototype Chain. You love it, you can explain how it works, because you’ve learned it from very early moments, before the First Standard was really made, and where as you remember is 4.2.1 Objects:

ECMAScript supports prototype-based inheritance. Every constructor has an associated prototype, and every object created by that constructor has an implicit reference to the prototype (called the object’s prototype) associated with its constructor. Furthermore, a prototype may have a non-null implicit reference to its prototype, and so on; this is called the prototype chain.

Wow… And if you, as me, indeed think this is one of the most important CS inventions, then how would you explain that effect it made on you, and all the possibilities your imagination produced when you were reading it?

Let’s get back again to the beginning. 1995 is here. You are Brendan Eich, and you have to invent new programming language. Probably you like Lisp or Scheme, at least in some parts. And there also is an Inheritance Problem you have to solve somehow: cause there must be some sort of OOP in that new language. So think: you have to mix all the things you like and might be some things you don’t like, and make this coctail Good Enough for nobody will see the difference between, until the moment there is a real reason to look inside.

And now the question is again:

how will you go with Inheritance?

Let now switch back to our regular life. What all we know about Inheritance? Some obvious parts of answers to this question:

Most of all life is based on Genome. It is a storage of data about probable creature properties and behaviour. Each one of us can infer it and own it’s part by being alive from previous life cycle generation.
You can make creature using two techniques: combining two predecessors or by monocous cloning one of them. For sure, today you can mix some genome parts from more than two, but this is not so natural and obvious.
Time matters. If some necessary properties are not yet invented or not exists anymore, you are unable to inherit them, you can only re-create them from scratch being genome designer. And also there is a Legacy of something you own from your predecessors not through genome but by law of property, and this might be important too.

Then, here we are now again, and the right question for our newly crafted language is:

Inheritance of What we have to design?

And, in any ways, we have to be able to fill the gaps between programming and life, while solving this Inheritance Problem, just because if then we will not be able to name this as an Inheritance at all.

And yet one moreover: we are in 1995, using very powerful PC with only 32Mb of memory, and we trying to implement Scripting Language, so we have to take care of this memory, we have to be able to use as small amount of it as it can be possible. Each piece of data, especially Strings, consume a lot of memory, and we have to be able to define that piece only once, and then make reference as much times as we need to have an access to our data through some techniques.

Now we can see how hard that question was.

There is a popular opinion, that “JavaScript made of Objects”, so we can answer the question of what have to Inherit from and to: Objects. And thinking of on that memory economy we have to store our data in Objects, also, mixing their references to data between Inherited properties of that Objects. Now we can see Why being in 1995 we indeed need a design based on a prototype chain: it will help us to gain the memory economy as far as it is possible. And I think it is still the point that matters.

And here we can again rely on design. Based on the opinion “everything is an Object” we might be able to Clone something. And what is Cloning? As I think, describing our requirements we might mean something like Structure Clones, or Shallow Copies, or some of modern Object.assign ancestors. Back in 1995 we can use just structure copy, therefore we can use some of code that works with for (var i in ClonedObject){} concept for doing this, because it was already invented for the first version of standard: as you can see, this might still be working as well

    // back in 1995 cloning
    // it is not deep clone,
    // though we might not need deep at all
    var cloneProps = function (clonedObject, destinationObject) {
      for (var key in clonedObject) {
        destinationObject[key] = clonedObject[key];
      }
    };

Also I’d recommend to take a peek deep-extend for understanding of making clones with JavaScript instead of obvious for... in implementation. Then, let’s try to imagine how using this Cloning definition sequentially, will help us to reach the following explanations of cloning pattern seems to be working in the past old ancient times:

Object from Constructor cloning: we will use Constructor for making at least two new different Clones: clone1.foo == clone2.foo

    // cloneProps is described above
    var SomeConstructor = function (clonedObject) {
      cloneProps(clonedObject, this);
    };
    var someExistingObjectToClone = {
      foo : 'bar'
    };
    var clone1 = new SomeConstructor(someExistingObjectToClone);
    var clone2 = new SomeConstructor(someExistingObjectToClone);

Constructor from Constructor cloning: we will use one Constructor for implementing behaviour of another one Constructor: AnotherConstructor makes the same as SomeConstructor, and we don’t use cloneProps

    var SomeConstructor = function () {
      this.a = 'cloned';
    };
    var AnotherConstructor = function () {
      // Function.prototype.call
      // was already invented in 1st ECMA-262
      SomeConstructor.call(this);
    };

Constructor from Object cloning: we will use Object for making at least two new Constructors with props cloned from that Object: calling SomeConstructor behaves the same as calling OtherConstructor

    var existentObject = {
      foo : 'bar'
    };
    var SomeConstructor = function () {
      cloneProps(foo, this);
    };
    var OtherConstructor = function () {
      cloneProps(foo, this);
    };

Object from Object cloning: we will use Object for making at least few new different Cloned Objects. So it is just cloneProp(cloned, destination) example as it’s described above.

As we can see, cloning is obvious, it is ok, it works fine, but…

How well we will make an Inheritance it for Instances using Combinations of Predecessors technique?

Inherit Object from Constructor: as it is a Constructor Purpose itself, so this might be used as well: this is a common pattern, described everywhere

    var existentObject = {
      foo : 'bar'
    };
    var SomeConstructor = function () {};
    SomeConstructor.prototype = existentObject;

    var inheritedObject = new SomeConstructor();

    // we have no instanceof yet in ECMA 262 of 1995
    // therefore we are unable to rely on this
    window.alert(inheritedObject.foo); // bar

Inherit Constructor from Constructor. No doubt, the first who did this was genius. This is also classic example everybody knows. Here could be a much more “advanced” example, though nothing for

    var FirstConstructor = function () {
      this.foo = 'bar';
    };
    var InheritedConstructor = function () {
        FirstConstructor.call(this);
    };
    InheritedConstructor.prototype = {
      bar : 'foo'
    };
    InheritedConstructor.prototype.constructor = FirstConstructor;
    var inherited = new InheritedConstructor(); // { foo : 'bar', bar : 'foo' }

Inherit Constructor from Object: you just rely on .prototype = object each time you make an Inheritance, therefore nothing to describe here additionally, it is always included, and any time you can change199x Constructor.prototype and it will Bubble through all of inherited Instances immediately, because memory is shared among them.
Inherit Object from Object: that is what it is, Again! You just put any Existing Object to Constructor.prototype and after making construction calling new Constructor you will get newly Inherited Instance of that Existing prececessor Object. And, you have Explicitly put Existing Object to Constructor.prototype, only then there will be implicit reference. And only then instanceof, which was initially described almost four years after Prototype Chain aroused in JS, will rely on that Constructor.

But yet one thing from Standart: do this all as deep as it will be necessary ...

... and so on ...

for our inheritance Trie’d prototype chain of 1995.

Let’s try make Instance Inheritance really deep in1995

Indeed, let assume we have two Instances { objects }, not the Constructors, but just plain Objects. And we wish to inherit one from another, and probably from another, and another, as the Standard says and so on?

But How?

Let’s look further, deeper. The right question here is, again that we noticed before: Inheritance of What we have to design?

We don’t need that Instances itself. We need their properties: associated data, consuming memory; and also we need some behaviour: methods utilising that data. It would be Fair enough if there will also be some ability to check what from and where to we are going to Inherit. It would be also good if we can Re-Produce that design of Inheritance Pattern in future, meaning if and when we Inherit One from Another we will always get the same result, regarding to what we expect by description (contract). Though it might be also useful to fixate that creation moment somehow, cause, indeed, predecessors might change during time, and it would be not so nice we will change successor giving respect to that changes.

As all of our code is a combination of data and behaviour, would it be nice that we are mixing them together utilizing that Inheritance pattern?

As for me this all looks like what we see when we observe Life in all of it majestic forms. From the earlies One-Cell Creatures to their Multi-Cell Successor and then other Successors, then to the Animals… and then to humans and humanity, Tribes, Civilizations and to the Intelligence, to Space and AI and going to the Galaxy, to Stars…

and:
“ … All we need to do is make sure we keep talking … ”

that incredibly mindful quote from Stephen Hawking which was then popularised by Pink Floyd’s awesome masterpiece.

And Programming Languages, utilizing Message Passing and Flow Based concepts are the Successors of that Idea. From just Raw Data we develop everything on the top of this ground level API. I think it is an Art as it is, and we might see as it works for JavaScript as well, deeply nested in language structure: referencing data structures through prototype chain.

So, let suppose we have both Parents, they communicate (keep talking) through time, and then one moment they decide to combine their emotions and feelings together bringing a Child. And this Child then grown, meeting another grown Child, they communicate (keep talking) and deliver another child. And again and again and again, from the ancient times to exact this moment: this is the Circle of Life.

And as we can see, naturally we have to use Two Parents, no less or more, cause if we use one, it will be cloning, if we use more than two, it would be engineering: Designed Genome of the DNA.

Two creatures, not Less or More. And they combine their properties using Inheritance, and then their children become owners of their Legacy. And each moment they combine themselves, they give us new kid. It is so simple.

Sounds strange, though, yes, we have all the parts we have to have to craft Inheritance pattern in JavaScript starting from 1995. And the main part is that 4.2.1 Objects, with it’s implicit referencing through the prototype.

And this just as it is, you combine Parent Object with ParentConstructor through it’s*.prototype* and then this Constructor will probably make you ChildObject when you say new keyword: this is so simple, so obvious, and so terrific

    var ParentObject = {
      foo : 'bar'
    };
    var ParentConstructor = function () {};
    ParentConstructor.prototype = ParentObject;

    var ChildObject = new ParentConstructor();

    // starting from 1995 and then ECMA 262
    // we are able to say new
    // each time we need a ChildObject

Here we have both parents, and then the moment when we say new we ask them to communicate. If they don’t wish to communicate process will fail with an error, and Life (js runtime compiler) will say you what went wrong.

And then, sure, we are asking about Genetic Tree or, which might be much more simplier about some sort of Genealogy. And the answer is the same, your Child Object is grown, and become Parent Object, then met another Constructor Object and when you say “new” — awesome:

    // this Assignment is just to show it grew up
    var ChildObjectGrownToParent = ChildObject;

    var AnotherConstructor = function () {};
    AnotherConstructor.prototype = ChildObjectGrownToParent;

    var SequentialChildObject = new AnotherConstructor();
    // checking Life Cycle ;^)
    console.log(ChildObject instanceof ParentConstructor); // true
    console.log(SequentialChildObject instanceof ParentConstructor); // true
    console.log(SequentialChildObject instanceof AnotherConstructor); // true

If you combine both examples, you will see working result of Inheritance Genome. And you can continue doing this as far in deep as it would be necessary!

I indeed hope this was the main Idea when design of Prototype Chain was crafted, because, as all we know this way causes some neat problems…

1: Community … As you can easily check, assignment to*.prototype* of ParentConstructor or AnotherConstructor is a very strong Social Contract for our Tribes, it produces references from ParentObject props (**.foo** ) to the Successors: kids, ChildObject and SequentialChildObject. If you will change that assignment, ouch, this references will gone forever. If you will cheat and reassign this references, oops, our kids will Inherit another object props. So, when combining parents with an assignment to*.prototype, probably we may tell we are going to create Family, because our parents might then produce a lot of children, and using “new*” keyword we may ask them to deliver another one as much time as it would be necessary for our Life Story. And then if we will destroy that.prototype based referencing we will destroy all of children properties they Inherited from the Family, such a crime drama. ;^)

Therefore this all is about Legacy and we have to take care of this, if we going to build reliable and maintaineable code. Sure respecting S.O.L.I.D., Liskov substitution Principle with Design by Contract, and then probably some of GRASP was not that problem in 1995. But it is obvious all that methodologies was not made from scratch, they were born much earlier.

2: Family … As we can easily check, our ParentObject allowed to be very frivolous in combining itself with other Constructors. It is not fair, but we are able to use as much Constructors as we wish, Inheriting ParentObject for making other families of children. From the other side each Constructor is tightly combined with ParentObject by assignment to*.prototype. When we wish no harm to children we should keep that reference as long and far in time as it is possible. We might name all this as tragedy and art of our Tribe History. Though also, it will protect us from Amnesia of what we referenced *from** and to, and why our children have all this Legacy. Giving a respect to Mnemosyne, it is realy easy to test our prototype chain Trie finding Artifacts what we did wrong.

3: Senescence … Our ParentObject and our Constructor could be somehow damaged in time of our Life (runtime) is doing what it was designed for. We might keep care of what we are doing, but nowone is protected from errors. And all that changes might bring some harm to our Inheritance Successors through that prototype chain. We should keep in mind about Memory Leaks. We might be able to destroy unnecessary parts of our code. We might be able to free the memory which is no more used for our Life Cycle. Also we should get rid of ability to bring Temporal Paradox to our prototype chains, though it is easy to reference Parent from Child, it might be very harmful, so we should not use that techniques of jumping from Future to Past. Finally it is possible to get full stack or pile of hardly reproducible Heisenbugs if we will try to measure something that is possible to change during time.

Chronicle of Solution

It is easy, obvious and very pleasant. Instead of thinking of our Constructor as Mommy and our ParentObject as Daddy let’s try to describe them in terms of Egg-Cell and… ough… Pollen. So when we will make a Zygote using “new” keyword, then, well, there is no harm to our Imagination.

Doing so, we will get rid of all that three problems. For sure then we need Egg-Cell Factory: Factory of Constructors. This might be each one of our Parents, might be Mother or Father, say as you wish, but the main point here is when we wish to say “new” we have to craft Egg-Cell and bring Pollen to it for growing up new Galanthus flower in such a far and still snowing and windy Spring of 2020:

    var Pollen = { season : 'Spring' };
    // factory of constructors 
    var FlowersFactory = function (proto) {
      var FlowerEggCell = function (sort) {
        this.sort = sort;
      };
      FlowerEggCell.prototype = proto;
      return FlowerEggCell;
    };
    var FlowerZygote = FlowersFactory(Pollen);
    var galanthus = new FlowerZygote('Galanthus');

That is it, now we see how it works. And don’t forget to check galanthus.season please!

For sure, Cyclomatic Complexity of solutions you will do utilizing this pattern is absolutely outstanding and as for me they can be compared with something you see solving Zebra Puzzle. Therefore I made a library, which might help with constructors chaining and memoization.

I can’t prove it, but this technique is successfully used for two decades from time to time when you need to be sure you did the best with Inheritance. As you can check it is more than testable, reproducible and maintainable. Didn’t telling the whole story here, we just rely on fact: JavaScript designed enough good even for making Genealogy Trie with Inheritance. Also we didn’t discuss the Class degradation, but you can easily implement FlowerEggCellClass instead of just FlowerEggCell inside of FlowersFactory. The main part here is as it is, if you will wish to use instanceof checking for your flowers you will see they all are made from that FlowerEggCell constructors you referenced through FlowerZygote. And, for sure, you can change FlowerZygote in time, it will bring no harm for FlowersFactory, it will continue be able to produce new “referenced” constructors in future according to the design you did.

My hope this article will reveal all uncertainty with how important .prototype keyword is, and then seeing usage of null in place of this for .bind(null, ... or .call(null, ... or .apply(null, ... you will feel Sorrow about current design state of the code style they made.

Thank You for reading this!

All in good time!

Sincerely yours V

PS 1:
RU version

PS 2:
Exported from Medium on February 25, 2020.
Canonical link on October 9, 2019.