Skip to main content
↑
↓
Spherical forums
Community for the
Sphere game engine
New?
Contact Us
to register an account!
1 Hour
1 Day
1 Week
1 Month
Forever
Community
Help
Search
Recent Posts
Log in
Contact Us
News
Spherical
Facebook
-
Twitter
-
Discord chat
New?
Contact us
to register an account!
General Discussion
Off-Topic Discussions
Thoughts on ES6 Classes
1
Print
Topic: Thoughts on ES6 Classes
(Read 2851 times)
previous topic
-
next topic
0 Members and 1 Guest are viewing this topic.
Flying Jester
Legendary Poster
Posts: 1,161
Logged
TurboSphere Developer
Thoughts on ES6 Classes
April 28, 2015, 06:54:57 pm
Someday, perhaps I will feel a different way. I'm also speaking a bit of hyperbole here to make my point. But this is what I think about ES6 classes.
They are not necessary, and generally a poor fit for JavaScript.
The way to do inheritance in JS, using prototypes has been called a hack, but it's actually inspired by how SmallTalk works. And SmallTalk is one of the older and more pure object-oriented languages. When prototypical inheritance is called a hack, it implies to me that writer is simply not aware of non-class-based object paradigms. Modifying and assigning to a prototype is simply another way to do it.
So why do I think that prototypical objects are a better fit for JavaScript? Because in JavaScript a function and an object are largely interchangeable, and because JavaScript is duck-typed.
I believe the functional aspect of JavaScript better suited to prototypical objects because with prototypical objects there is no need for a class definition. The constructor, a function,
is
the definition. You can add methods to it by adding to its prototype. This is better suited to functional programming, or a mix of functional and object-oriented programming, because now the object's definition is a function, and an object is (in a way similar to SmallTalk) a function that has a captured and maintained scope.
Duck-typing is quite useful here because it makes arbitrary extension of the prototype more natural. Since there is no formal class definition, you can attach anything to it and not be violating some definition. All that matters, the actual requirements of the 'class', is how it is used. Does it have a 'quack' method? The requirements
are
the usage.
Perhaps this is just a rationalization to have duck-typing. But it seems to work well here.
Maybe I'm just set in my ways. But I feel that in many ways, ES6 Classes are an extension that is solely to make programmers from class-based languages more comfortable. They don't add much value to JavaScript, except to make it look more like another language.
Learn some history?
The Flying Jester's Blog of Sorts
Fat Cerberus
Big Chungus
Posts: 2,774
*MUNCH*
Logged
Global Moderator
Sphere Developer
Re: Thoughts on ES6 Classes
Reply #1
–
April 28, 2015, 09:44:52 pm
I much prefer JavaScript's duck typing over classical inheritance myself, so you're not alone there. It makes it very easy to prototype stuff (no pun intended) because you can just hack together an object with the proper members for the task--you don't even need to write a constructor. Only later, when you've determined that your prototype works, do you refactor, which is itself painless because of the duck typing. Honestly I think people get insecure when a language gives them too much freedom. For whatever reason, people seem to actually
like it
when their compiler yells at them constantly. It's like how everyone gets into an tizzy over `==` vs `===` - sure, there can be issues if you're not careful, but it's not nearly as big a deal as everyone thinks it is.
If I had to guess why this is happening, I'd say it was due to pressure from CoffeeScript. Everyone seems to believe CoffeeScript is "what JavaScript should have been" to the point that internal style guides even dictate its use (GitHub, for instance). Personally, I can't stand CoffeeScript and avoid it like the plague.
In the end though, I'm not too worried. ES6 has a lot of awesome things in it too. The Proxy constructor, for instance, which is a cleaner, more well-thought-out version of Lua metatables, block scoping via
let
, etc. And backwards compatibility
has
to be maintained because otherwise you break 90% of the web.
Last Edit
: April 28, 2015, 09:47:41 pm by Lord English
neoSphere 5.9.2
-
neoSphere
engine -
Cell
compiler -
SSj
debugger
forum thread
|
on GitHub
1
Print
General Discussion
Off-Topic Discussions
Thoughts on ES6 Classes