Day 65: Prototypes in C and in JavaScript???

Started writing out an example program in C to get the longest line from a text file. The code used “function prototypes” to declare the utility functions before the main function so that they can be written below. I commented yesterday that I liked this style but I did not know the name for this pattern. It’s ironic because I have been reviewing my notes from my JavaScript studies and it is currently covering JavaScript prototypes. Now, these terms refer to different things respectively but it was funny how the word appears in both at the same time I’m studying each. Weird.

TLDR;

Okay, so here are the highlights of what I did:

  • Continued to work on the “Technical Questions” section of the book “Cracking the Coding Interview” by Gayle Laakmann McDowell. Within that, I continued my work on Tree data structures. Started trying to replicate the example pretty print functions provided in the article I am reading through. I had to pause working on my Horizontal Pretty Print project to better understand string/character manipulation in the C programming language. It is a bit of a detour but I imagine it will pay itself off in the long run. Continued reading the C programming book called “The C Programming Language” by Brian W. Kernighan and Dennis M. Ritchie. I am copying the example code to test it for myself. This is part of getting those reps in that I mentioned before. At the end of the day the language shouldn’t matter if I am comfortable and I understand the underlying concepts which are pretty consistent in all languages. It’s just about putting in the time. I wasn’t as productive as I would have liked to be today. I was a little tired but tomorrow I’ll be sure to make up for it… I hope!
  • I continued reading through chapter 6 of the book “Eloquent JavaScript” by Marjin Haverbeke. I am starting to read the book to help cover some insecurities I have about my knowledge of the language. I learned JavaScript on the fly through projects and YouTube videos. There are some core questions about the language that I don’t think I can answer, so hopefully this will help. I was reviewing my notes on prototypes today. In Chapter 6 the topic is covered alongside classes but is a little hectic. I tried to clean up my notes to help make things clear for myself. And of course I ran some test code to answer some of my odd ball questions. Next up is to lock down the concept and syntax for writing classes in JavaScript and how OOP concepts are represented in JavaScript.

JavaScript Prototype Notes:

In addition to a JavaScript object’s set of properties, all objects also have a prototype. A prototype is another object that is used as a fallback source of properties. It exists in a similar position as a class. When an object gets a request for a property that it does not have, its prototype (just like a class – I think) will be searched for the property. This will continue repeatedly up the hierarchy until the root prototype is reached. By default the ancestor of almost all prototypes is the Object.prototype. The Object.prototype is like the class that all JavaScript objects are instances of. It contains methods that by default can be found in all JavaScript objects e.g. the .toString() method. All these methods (and properties maybe…?) that exist in the Object.prototype object can be overridden (polymorphism) but by default will exist.

console.log(Object.getPrototypeOf({}) == Object.prototype);
// → true

// The Object.prototype has no prototype because it is the root.
console.log(Object.getPrototypeOf(Object.prototype));
// → null

Again, the prototype relations of JavaScript objects form a tree-shaped structure, and at the root of this structure sits Object.prototype. The example toString method converts an object to a string representation.

Many objects don’t directly have Object.prototype as their prototype but instead have another object that provides a different set of default properties. Functions derive from Function.prototype, and arrays derive from Array.prototype but ultimately they still share the root of Object.prototype.

console.log(Object.getPrototypeOf(Math.max) == Function.prototype);
// → true

console.log(Object.getPrototypeOf([]) == Array.prototype);
// → true

console.log(Object.getPrototypeOf(Function) == Function.prototype);
// → true

console.log(Object.getPrototypeOf(Function.prototype) == Function.prototype);
// → false

console.log(Object.getPrototypeOf(Function.prototype) == Object.prototype);
// → true

You can use Object.create() to build an object with a specific prototype. Here is an example:

let protoRabbit = {
  // shorthand syntax for writing a method for an object.
  speak(line){
    console.log(`The ${this.type} rabbit says '${line}'`);
  }
};

let killerRabbit = Object.create(protoRabbit);
killerRabbit.type = "killer";
killerRabbit.speak("SKREEEE!");
// → The killer rabbit says 'SKREEEE!

In the example above, the prototype that is given to the rabbit is the one we provided (protoRabbit) but the default root prototype of Object.prototype remains the same. The “proto” rabbit (protoRabbit) acts as a container for the properties that are shared by all rabbits (like a class in OOP). An individual rabbit object, like the “killer rabbit” (killerRabbit), contains properties that apply only to itself—in this case its type—and derives shared properties from its prototype (class).

If we wanted to not have the default Object.prototype exist for an object that we constructed we could simply pass in a null value for the Object.create(prototype) function. However, I don’t think this is possible with shorthand object declaration like `let object = {};“

let freshObject = Object.create(null);

console.log(Object.getPrototypeOf(freshObject) == Object.prototype);
// → false

console.log(Object.getPrototypeOf(freshObject) == null);
// → true

Conclusion

That’s all for today. This is my sixth round of the “#100daysofcode” challenge. I will be continuing my work from round five into round six. I am currently working through the book “Cracking the Coding Interview” by Gayle Laakmann McDowell. My goal is to become more familiar with algorithms and data structures. This goal was derived from my goal to better understand operating systems and key programs that I use in the terminal regularly e.g. Git. This goal was in term derived from my desire to better understand the fundamental tools used for coding outside of popular GUIs. This in turn was derived from my desire to be a better back-end developer.

I have no idea if my path is correct but I am walking down this road anyways. Worst case scenario I learn a whole bunch of stuff that will help me out on my own personal projects.