prototypes versus classes [closed] - javascript

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
Steve Yegge recently posted an interesting blog post on what he calls the universal design pattern. In there he details using prototypes as a modelling tool, instead of classes. I like the way this introduces less coupling compared to inheritance. But that is something one can get with classes as well, by implementing classes in terms of other classes, instead of inheritance. Does anyone else have success stories of using prototypes, and can maybe help explain where using prototypes is advantageous compared to classes. I guess it comes down to static modelling versus dynamic modelling, but more examples would be very welcome.

One interesting bit is that it's easy to make a prototype-based language act OO but it's difficult to make an OO language act prototype-based.
Alex Arnell's inheritance.js is a short and sweet chunk of code that makes JavaScript act OO, complete with access to the parent 'Class'.
Here's one of John Resig's solutions to the same problem: http://ejohn.org/blog/simple-javascript-inheritance/.
Chapter 16 of Programming in Lua describes object orientation in Lua. Specifically, section 16.2 gives a nice example of inheritance.
It's not entirely clear what OO as prototype would look like, aside from composition versus inheritance as you mention.
A prototype language makes complex inheritance behavior easy. You can implement multiple inheritance, mixin-like behavior, or just pick and choose what you want from one object to add to another.
Wikipedia's article mentions: "Advocates of prototype-based programming often argue that class-based languages encourage a model of development that focuses first on the taxonomy and relationships between classes. In contrast, prototype-based programming is seen as encouraging the programmer to focus on the behavior of some set of examples and only later worry about classifying these objects into archetypal objects that are later used in a fashion similar to classes."
That's not to say the prototype paradigm is all pros and no cons. If OO is more restrictive, it's because it chooses to be. I can see where all that flexibility might get you into trouble if you aren't careful.

Prototypes are a form of inheritance, it's just that objects inherit attributes and behavior directly from other objects, instead of getting their attributes and behavior from their class, which inherits from other classes.
For examples, check out any object oriented code in a prototype based language like, for example, JavaScript.

For those interested, NewtonScript was (is) a dual language: you had prototypes and you had classes. You could choose whether to inherit from a class, from a prototype or from both.

Related

Any Reason To Not Use ES6 Classes? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have never really worked too in depth in Javascript. So just starting to dig into it more, I have learned about the "new" syntax for JS: MDN
I understand that basically it is exactly the same as before just with a different way to construct the code.
Obviously there is always a reason to learn techniques and variations, but what would make it worth my time to learn prototyping syntax, when using the updated syntax is more familiar to learn?
*One reason I can think of is just for understanding examples from before ES6. Almost everywhere the code is written with prototyping.
The only reason to avoid the class syntax is if you want your code to run in an environment where the class keyword is not supported. And, even then, you could write with class and transpile your code to ES5 compatible code if you wanted.
So, there's really no reason to avoid using class.
but what would make it worth my time to learn prototyping syntax
Even though you may code with class, here are some good reasons to fully understand how the prototype object works:
Javascript is a prototype-based language. Even though it is now using the class keyword, it's a prototype-based language, not really a class based language. You should know and understand what that means.
Older code will be written using assignments to the prototype so you will want to be able to quickly understand how that code works.
The class syntax is just manipulating the prototype under the covers so fully understanding how the class syntax works requires fully understanding how the prototype works.
There are programming structures that are sometimes very useful that the class syntax cannot create such as mixins where you may still need to work with the prototype.
So, I would suggest learning how objects are defined with the prototype object because then you will understand what the class syntax is actually doing. It's not particularly hard. Reading a few articles about how the prototype object works and then creating an object and then deriving from it using the .prototype object syntax is all you really need to do to get a handle on it. Then, I'd suggest creating the exact same object definition and then deriving from it using both the class syntax and by assigning to the prototype and then you can really see the parallels.

When should one choose prototypal inheritance vs functional inheritance? [duplicate]

This question already has answers here:
Use of 'prototype' vs. 'this' in JavaScript?
(15 answers)
Closed 9 years ago.
I've been reading through JavaScript: The Good Parts and I'm currently on "Chapter 5: Inheritance."
From what I understand, using functional inheritance is preferred because it allows privacy for the properties and variables of an object while still allowing them to be called using methods outside of the object. However, it does seem like there is an advantage for prototypal inheritance because you can create a prototype object fairly easily (which makes understanding what the object is, to me, a little more concrete).
When should I choose one over the other? Should I always use functional inheritance whenever possible? Or are there "better" guidelines that I can follow to make that determination?
I've seen very little code that uses functional techniques as the primary form of inheritance. The vast majority I've seen uses prototypal inheritance. It's fast and easy to implement, and seems most natural to JavaScript.
That's not to say that functional inheritance should never be used, but I think you'll find prototypal more than sufficient for most applications.
Let's not also forget that you can still use some functional techniques within your prototypal inheritance, like giving each object it's own version of a function that closes over a variable in the constructor. So it doesn't need to entirely be one or the other.
Most important is to understand the concepts of prototypes and functions/closures. This alone will give you what you need to know in order to make appropriate decisions.

Node JS, traditional data structures? (such as Set, etc), anything like Java.util for node? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 months ago.
Improve this question
I'm loving node JS and, coming from a Java background, am interested in even trying it out for some projects where node may seem a bit of a stretch, such as a search engine project.
One thing I've been a bit confused by is it seems JavaScript is lacking traditional data structures, for example a set, which has a precise definition extending even beyond computer science as it has been used in mathematics before computers existed (basically a list that doesn't allow duplicates). It seems when using node JS there is no library like Java.util that has these basic data types that I have grown accustomed to, I realize I could create them myself but this just adds more overhead to the project.
Are there any libs for node (or JavaScript in general) that address this? I think node has a lot of potential to replace the use of a language like Java for a lot of projects as it has so many advantages in terms of development speed, but having to recreate data structures that are taken for granted in a more mature platform could be too much overhead for a small project.
I apologize if there are other questions like this, however I spent some time searching and didn't come up with much.
es6 has a Set class built in:
new Set([iterable]);
see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set
Collections.js has Lists, Maps, Queues, Sets, and Heaps, all with consistent interfaces. Github.
it seems JavaScript is lacking traditional data structures...
Yes, this is javascript, the very concept and implementation of data structure is done quite differently from languages like Java.
I'm not sure that you're really going to find what you're looking for with Javascript. Howver, there are some libraries like underscore that should make it easier to build the type of structures that you want.
Its no longer true that node.js doesn't have Set and Map objects among other things. node.js has had them since at latest v12.
But of course, if you want libraries like java has, check npm or github. You're not limited to what comes standard in node.js.
Have you looked into Underscore.js? http://underscorejs.org/
It's not a one to one with java.util but it provides a bunch of commonly needed utility functions.
As a lighter and faster alternative to Underscore.js, Lo-Dash (http://lodash.com/) is getting traction those days... But this is not Java.util! :-)
Have a look at this one: https://github.com/chenglou/data-structures
I think it fits what you are looking for.
js-sdsl
A javascript standard data structure library which benchmark against C++ STL.
This library has strict time complexity guarantee and can be used with confidence.
The latest beta version includes iterator functions which can be used like iterator in c++.
Included data structures
Vector
Stack
Queue
LinkList
Deque
PriorityQueue
Set (using RBTree)
Map (using RBTree)
HashSet (for reference only)
HashMap (for reference only)
Usage
To help you have a better use, we provide this API document.

learning ecma script/javascript directly from the reference [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am trying to learn Javascript.There are some excellent books and great authors that became standard in JS world - As I can see, they all have their own way of interpretation of language. It can be sometimes confusing for the novice in Javascript.I wonder, how usefull can be to learn directly from ECMAScript language specification as it was published by the authors of the language ?
It's probably much better to learn from the tutorials, as the specification is designed for people implementing JavaScript parsers/interpreters, not for people learning JavaScript itself.
If you want to learn from a reference, the MDN is a fantastic resource. There are also plenty of tutorials out there.
The specification is optimized for defining the language from the point of view of its implementors. It is not optimized for teaching it to someone that is new to the language.
A good learning reference has also many things that are not covered in the language spec, like common APIs (like the DOM and a JS framework) and common patterns (ex.: the module pattern, namespaces, etc...). While it is true that some people might have some coding practices you don't agree with you should not immetiately dismiss what they say, unless you really want to learn everything and fall into every trap yourself. As long as you have a mental framework of what you consider to be the best practices in general you should be able to identify what you agree with or not.
JavaScript is one of the most controversial languages in existence, there is no clear author and no clear documentation.
The best project I know of is Mozilla Developer Network (or MDN), it's pretty extensive and comprehensive.

Javascript Best Practices [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What are some good resources to learn best practices for Javascript? I'm mainly concerned about when something should be an object vs. when it should just be tracked in the DOM. Also I would like to better learn how to organize my code so it's easy to unit test.
Seconding Javascript: The Good Parts and Resig's book Secrets of the Javascript Ninja.
Here are some tips for Javascript:
Don't pollute the global namespace (put all functions into objects/closures)
Take a look at YUI, it's a huge codebase with only 2 global objects: YAHOO and YAHOO_config
Use the Module pattern for singletons (http://yuiblog.com/blog/2007/06/12/module-pattern/)
Make your JS as reusable as possible (jQuery plugins, YUI modules, basic JS objects.) Don't write tons of global functions.
Don't forget to var your variables
Use JSlint : http://www.jslint.com/
If you need to save state, it's probably best to use objects instead of the DOM.
I disagree to the "use a framework" statement to some degree. Too many people use frameworks blindly and have little or no understanding of what's going on behind the curtains.
I liked JavaScript:The Good Parts by Douglas Crockford although it's focused entirely on the language and ignores the DOM altogether.
If you don't feel like reading you can watch this video: JavaScript the good parts by Doug Crockford.
Probably the single most important thing is to use a framework, such as jQuery, or prototype, to iron out the differences between browsers, and also make things easier in general.
YUI Theatre has a bunch of videos (some with transcripts) by Steve Souders, Douglas Crockford, John Resig and others on JavaScript, YUI, website performance and other related topics.
There are also very interested google tech talks on Youtube on jQuery and other frameworks.
You can pick up a lot from Pro JavaScript Techniques, and I'm looking forward to Resig's forthcoming Secrets of the JavaScript Ninja.
As an addendum to the Crockford book, you may also want to check out this piece Code Conventions for the Javascript Programming Language. I also have a slightly different suggestion: instead of using a JS library off the bat, why not create your own? You may write a crappy library (as I did), but you'll learn something in the process. You have existing examples you can use as models. Also, to help give you an understanding of JS design patterns, I shall recommend another book, 'Pro Javascript Design Patterns'.

Categories