Also I don't see a big difference between using class-based and not classed based OOP.
In class-based languages the object's "membership" is static - i.e. an object cannot change "classes" during it's lifetime. In JavaScript an object's capabilities can be augmented after construction - effectively changing its "class".
DCI (Data Context Interaction) for example needs objects to dynamically present roles while not changing their identity. Static class membership of mainstream class-based OO languages gets in the way, requiring workarounds. This lead to trygve.
So whether or not you see "lifetime class membership" as a feature for objects depends on your particular needs.
as OOP is mostly about encapsulation, and this is Kay way of thinking.
Erlang (and independently the Actor model) uses a shared-nothing asynchronous message passing system. So data-hiding isn't an objective but simply the result of sharing nothing.
Other than that many FP languages don't care about data-hiding but simply respect the notion of a opaque data type when necessary. As Rich Hickey observed:
"And if you have a notion of “private”, you need corresponding notions of privilege and trust. And that adds a whole ton of complexity and little value, creates rigidity in a system, and often forces things to live in places they shouldn’t."
So encapsulation may not be as desirable in all contexts, possibly not even in most.
so how you can state that TS is more object oriented if there is no real difference?
By taking the position that TS makes a functional style harder to practice compared to an object-oriented style. Just because it doesn't stop determined individuals doesn't weaken the claim. Typing OO code in TypeScript is fundamentally easier than typing functional code (which is also less awkward to type in a dedicated FP language). Given that JavaScript isn't statically typed it doesn't discriminate either way.
In a world with TypeScript but without JavaScript I doubt something like JavaScript Allongé would have ever been written.
Adding types to that is not easy task, but I think TS made a great progress with that.
TypeScript's priority was to type JavaScript's imperative aspects - so the later additions feel bolted on and awkward.
but saying that it is something better is overstatement,
I didn't imply it was better. Some would say it is better because it eliminates inheritance, forcing the use of composition. The point is that there are different ways of practicing object-orientation - class-based is just one of them. JavaScript's OO was inspired by Self.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In class-based languages the object's "membership" is static - i.e. an object cannot change "classes" during it's lifetime. In JavaScript an object's capabilities can be augmented after construction - effectively changing its "class".
DCI (Data Context Interaction) for example needs objects to dynamically present roles while not changing their identity. Static class membership of mainstream class-based OO languages gets in the way, requiring workarounds. This lead to trygve.
So whether or not you see "lifetime class membership" as a feature for objects depends on your particular needs.
Erlang (and independently the Actor model) uses a shared-nothing asynchronous message passing system. So data-hiding isn't an objective but simply the result of sharing nothing.
Other than that many FP languages don't care about data-hiding but simply respect the notion of a opaque data type when necessary. As Rich Hickey observed:
"And if you have a notion of “private”, you need corresponding notions of privilege and trust. And that adds a whole ton of complexity and little value, creates rigidity in a system, and often forces things to live in places they shouldn’t."
So encapsulation may not be as desirable in all contexts, possibly not even in most.
By taking the position that TS makes a functional style harder to practice compared to an object-oriented style. Just because it doesn't stop determined individuals doesn't weaken the claim. Typing OO code in TypeScript is fundamentally easier than typing functional code (which is also less awkward to type in a dedicated FP language). Given that JavaScript isn't statically typed it doesn't discriminate either way.
In a world with TypeScript but without JavaScript I doubt something like JavaScript Allongé would have ever been written.
TypeScript's priority was to type JavaScript's imperative aspects - so the later additions feel bolted on and awkward.
I didn't imply it was better. Some would say it is better because it eliminates inheritance, forcing the use of composition. The point is that there are different ways of practicing object-orientation - class-based is just one of them. JavaScript's OO was inspired by Self.