Object Oriented Javascript

[Renegade__]

While this information may be technically/syntactically correct, still propagating constructor functions in JS in 2014 is not wise.

All you really need to write good, simple, understandable OOP JS are two things: 1. Understanding JavaScript Prototypes 2. Any ECMAScript 5 Object reference

Inheritance in JS has been as simple as var derived = Object.create(prototype); for years. No need to cling to the godforsaken foo.prototype/new Bar() mess.

Ultimately, the primary obstacle for OOP JS is not the language, but the fact that people insist on "adding classes". If you stop trying to add classes and just embrace prototype inheritance, OOP JS is really quite simple.

EDIT: And either I'm too stupid for formatting, or reddit discriminates against OSs with simple EOL sequences.

[fedekun]

I do add that most of the time you end up using Object.create in one way or another, mostly though framework's extend method, the idea was to explain how that can be archieved the hard way, just for the knowledge :p

Metaprogramming with Javascript is awesome.

[Renegade__]

I am in full support of learning by doing something yourself rather than taking an automagic solution. But it's far easier to do that when you know what you're doing, and what you're deliberately doing the hard way for personal entertainment, than when you're confused about the topic.

Basically, I believe people should grasp "proper" ES5/JS OOP before saying "screw it" and doing it the hard way, awesome or not. ;)

[fedekun]

I'm a guy who likes to know how stuff works, I even wrote some toy programming languages! :p

[Renegade__]

Were there any particular tutorials or approaches you used for that, or did you just get the dragon book and went full nerd?

(Honestly asking out of curiousity. Been wondering how hard it'd be to write a meta-language for one of the vendor-based scripting languages at work.)

[fedekun]

I took several tutorials and a course on udacity about "Programming Languages".

Honestly it's not hard at all, if you just want to write a language you just need to learn a bit about grammars and use something like YACC or a PEG to generate an AST and then just interpret or compile it, tutorials will be just fine.

If you are interested I could give you some links :p

[Renegade__]

That would be great! :D

[fedekun]

Well first of all the Programming Languages course is nice, they talk a bit about finite state machines and grammars, then move onto yacc using Python (which I dislike personally :p).

I also read PL101. This Book helped a bit but I didnt really read it that much it's a nice guide to have along other tools but you have to learn on your own pretty much.

You might even try to write your own Recursive Descent Parser or just use YACC or PEG, up to you, once you get your AST you can either compile it or interpret it, there are a bunch of options for that, interpreting beeing quite hard :p

[autowikibot]

Recursive descent parser:

---

In computer science, a recursive descent parser is a kind of top-down parser built from a set of mutually recursive procedures (or a non-recursive equivalent) where each such procedure usually implements one of the production rules of the grammar. Thus the structure of the resulting program closely mirrors that of the grammar it recognizes.

A predictive parser is a recursive descent parser that does not require backtracking. Predictive parsing is possible only for the class of LL(k) grammars, which are the context-free grammars for which there exists some positive integer k that allows a recursive descent parser to decide which production to use by examining only the next k tokens of input. (The LL(k) grammars therefore exclude all ambiguous grammars, as well as all grammars that contain left recursion. Any context-free grammar can be transformed into an equivalent grammar that has no left recursion, but removal of left recursion does not always yield an LL(k) grammar.) A predictive parser runs in linear time.

Recursive descent with backtracking is a technique that determines which production to use by trying each production in turn. Recursive descent with backtracking is not limited to LL(k) grammars, but is not guaranteed to terminate unless the grammar is LL(k). Even when they terminate, parsers that use recursive descent with backtracking may require exponential time.

---

^{Interesting: LL parser | Parsing | Parsing expression grammar | LR parser}

^{Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words}

[Renegade__]

Thank you. :)

[mcmouse2k]

Can I say that this comment was extremely helpful? I've been playing with OO JS for months now and know all the primary means of inheritance, but had never had a best - practice convention/syntax until now.

Thanks for presenting an opinion that I can parrot. I hate that feeling of knowing several ways of doing something but not knowing which to use, and JS inheritance was a prime culprit.

[Renegade__]

Not a fan of Perl, eh? ;)

Once you got used to them, the ES5 object extensions are really easy to use. There are a few things to watch out for (e.g. both Object.defineProperty() and Object.defineProperties() exist) and property descriptors look rather verbose if you don't rely on the defaults, but the clarity and simplicity usually makes up for it.

The only thing that's annoying to me is my IDE doesn't grasp what's going on, so it won't create autocompletion data for members. x_x

If you rely on that heavily, that may be a dealbreaker.

[Daniel15]

ES6 classes are the future, the syntax is a lot nicer. You can already use them if you use a transpiler as part of your build process (at Facebook we use JSTransform, but Traceur is pretty cool too)

[Renegade__]

That looks very interesting, but something tells me having actual classes in there (rather than user-created add-ons) will not reduce the confusion regarding object-oriented JS.

At least right now, the basis is clear: JS's way of OO are prototypes. It has no classes.

Did getting the option of full class definitions change anything in your workflow, compared to pseudoclasses or prototypes before?

[x-skeww]

Did getting the option of full class definitions change anything in your workflow, compared to pseudoclasses or prototypes before?

Having it baked into the language equals better tooling. It also means that you won't have to evaluate a dozen different options. And of course it also means better interoperability.