Object-Oriented Javascript

submitted by fschmidt from self.programming

Javascript encourages this:

function Counter(init) {
    this.count = init || 0;
    this.inc = function() { return ++this.count; };
    this.dec = function() { return --this.count; };
}
let c = new Counter(10);
console.log(c.dec());
console.log(c.dec());

But Javascript classes are a disgusting mess full of quirks. So just don't use them. Instead do this:

function newCounter(init) {
    let counter = {};
    counter.count = init || 0;
    counter.inc = function() { return ++counter.count; };
    counter.dec = function() { return --counter.count; };
    return counter;
}
let c = newCounter(10);
console.log(c.dec());
console.log(c.dec());

No class crap here, just simple code.

all 15 comments
sorted by:
top
newinsightfulfun

[–]x0x7 1 insightful - 3 fun1 insightful - 2 fun2 insightful - 3 fun -  (0 children)

Yes.

There is a reason why object orientation began to decline in use inside javascript the more and more years its developers had in it.

Until large industry decided they wanted to adopt it and they needed their army of shit devs to have more familiarity.

I would change your code though. Returning an object from a closure has good 1:1 with standard object orientation but you can have more than one variable in your closure. I also allows you to private things. Just declare your members as variables within the function.

function newCounter(init) { let counter = init || 0; return { inc:()=>++counter, dec:()=>--counter, count:()=>counter };

You can also just use the argument as counter and arrow functions support defaults.

const newCounter = (counter=0)=>{ return { inc:()=>++counter, dec:()=>--counter, count:()=>counter }; }

I do still prefer to use the function keyword when doing named functions though if I'm not using defaults. It just stands out a little better and I think a named function deserves to.

[–]BanditMcFuklebuck 1 insightful - 3 fun1 insightful - 2 fun2 insightful - 3 fun -  (3 children)

Wow, you can overload a function junst by putting ||??? so if there's a value for init it initializes it but if there's not it junst uses 0! I don't think Java or C++ can do that can they??

[–]IMissPorn 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (2 children)

It's an interesting quirk. In JS "A || B" technically means "If A is true, then A, otherwise B". This does make it function like you'd expect a logical OR to do, but it has more arcane uses as seen here. I'm kind of conflicted on stuff like this, it's fun to learn and can be handy, but it doesn't make for the most readable code. I'm kind of surprised OP finds it acceptable considering how much he hates other weird shortcuts.

[–]fschmidt[S] 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (1 child)

This idiom is readable. If you read "||" as "or" then "x = y || z" makes sense. This is in contrast to arrow functions and default parameter values that you see x0x7's code which just don't make sense unless you know what they are.

[–]IMissPorn 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (0 children)

I see. I suppose that makes sense.

[–]jingles 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (0 children)

That is nice code. But can you develop an automated trading system? No fancy classes required.

I had a conversation with a professor of theoretical physics a while back.. he told me that he tried for several years and his code always failed.

It ain't easy.

[–]package 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (8 children)

Get with the times, old man:

class Counter {
    #count;
    constructor(init = 0) {
        this.#count = init;
    }
    inc() {
        return ++this.#count;
    }
    dec() {
        return --this.#count;
    }
    get count() {
        return this.#count;
    }
}

[–]fschmidt[S] 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (7 children)

I see it's gotten worse. Thankfully I am working with 11-year-old code that isn't pure modern crap. Here is your disgusting modern crap failing:

class Counter {
    count = 0;
    test() {
        function inner() {
            return ++this.count;
        }
        return inner();
    }
}
let c = new Counter();
console.log(c.test());
console.log(c.test());

Fails with: Uncaught TypeError: Cannot read properties of undefined (reading 'count')

[–]package 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (6 children)

I honestly have no idea what you are trying to convey here; if you write incorrect code in any language it will not give you the results you expect.

[–]fschmidt[S] 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (5 children)

Why is it incorrect? This works:

function newCounter() {
    let counter = {};
    counter.count = 0;
    counter.test = function() {
        function inner() {
            return ++counter.count;
        }
        return inner();
    };
    return counter;
}
let c = newCounter();
console.log(c.test());
console.log(c.test());

The disgusting modern code is only incorrect because of the moronic obscure rules of disgusting modern features. A good language is based on a few simple concepts. Thankfully if one sticks to a small subset of old Javascript, one actually has a reasonable language. Of course everything produced by modern scum is pure shit and should never be used.

[–]package 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (4 children)

Are you getting your panties in a bunch over the scoping of "this"? And acting like it's a modern issue? That nonsense has been around since the beginning, and is fixed by using arrow functions instead of "function" declarations, as arrow functions do not replace "this" within their own scope:

class Counter {
    count = 0;
    test() {
        const inner = () => {
            ++this.count;
        }
        return inner();
    }
}
let c = new Counter();
console.log(c.test());
console.log(c.test());

[–]fschmidt[S] 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (3 children)

You are obviously complete modern scum and I regret sharing the same planet with you. What you are saying is just fucked up beyond belief. Why should arrow functions behave differently from regular functions, that just makes things more confusing. Yes the "this" problem is old because Javascript should never have had object-oriented features like this in the first place. But at least the scum who added "class" could have fixed this issue within a class since this was new. But no, of course they didn't do this since they are depraved modern scum. The correct solution is mine, to reject all this disgusting crap and build objects strictly based on closures and not class-based nonsense.

[–]package 2 insightful - 2 fun2 insightful - 1 fun3 insightful - 2 fun -  (2 children)

Bro lmao why are you so attached to old js? Literally everyone hated old js when it was the norm, exactly because there were tons of weird quirks regarding scope, lifetimes, and mutability. Arrow functions specifically are made for callbacks and control inversion scenarios where the existing scope is more relevant than the function's own scope, which just so happens to be 99.999% of scenarios where you make use of anonymous functions. Word of advice if you're this far behind in your js skills and hate modern features, definitely avoid reading about async/await and the Promise monad; your brain will probably melt.

[–][deleted]  (1 child)

[removed]

    [–]Vulptex[A] 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (0 children)

    This comment is also removed for advocating violence.