Is this the worst thing known to man?

Is this the worst thing known to man?

class Foo {}
class Bar{}
function ensureFoo(foo: Foo) {
if (foo !== null && !(foo instanceof Foo)) {
// Should never happen, right? foo must be a Foo!
throw new Error();
}
}
ensureFoo(new Bar());


>no compiler error
>muh structural type system

jesus fuck. Why even has a type system this bad?

Attached: literally hitler.png (1187x1187, 23K)

Other urls found in this thread:

github.com/Microsoft/TypeScript/issues/13756
typescriptlang.org/play/#src=class Foo {} class Bar{} function ensureFoo(foo: Foo) { if (!(foo instanceof Foo)) { // Should never happen, right? foo must be a Foo! throw new Error(); } } ensureFoo(new Bar());
typescriptlang.org/play/#src=class Foo { getNumber() { return 0; } } class Bar { getNumber(): number { throw new Error('WHAT THE HELL'); } } function ensureFoo(foo: Foo) { if (!(foo instanceof Foo)) { // Should never happen, right? foo must be a Foo! throw new Error(); } } ensureFoo(new Bar());
typescriptlang.org/docs/handbook/type-compatibility.html
basarat.gitbooks.io/typescript/docs/types/typeGuard.html
twitter.com/NSFWRedditImage

If you're going to use a strongly typed language, why not just go with C++/Java/C#?

use kotlin, has an actual type system with non-nullable types, and it can be compiled into JS

Attached: 1524544186456.jpg (1000x1480, 130K)

... what if you want to build a web app? Gotta get to JS somehow. I'd rather use any of those if possible. I'd rather literally use just plain JS than TS.

But honestly Kotlin appears to be my lord and savior, I hope it takes off.

>>no compiler error
Because of the &&, the compiler will optimize and not let you know there's a problem until runtime. This is well known, CompSci 101 knowledge.

Would if I could. Work is stupid and is migrating to TS for all the frontend and node stuff we have. I'm trying to convince them Kotlin is superior but I fear the ship has sailed.

The whole point is that
>the worst thing known to man
Is vanilla Javascript.

Typescript let's it suck just a bit less, for people forced to use it.

can you explain, why does it let you pass a Bar to a function that says it only accepts Foo?

The problem with totally different languages like Kotlin and Clojurescript is that every library and third party thing you want to use is going to be Javascript. Even with "bindings" it's terrible dealing with a nice language and also having to deal with a shit one.

Typescript let's you make you own code better whilst still being basically Javascript.

>Js

You realize OCaml can compile to JS bytecode right? Strongest type system you can use next to some kind of purely functional language. There's also 'ReasonML' which is essentially OCaml but with different syntax and extensive libraries for web development made by FaceBerg

yes. javascript doesn't have types. deal with it and stop shitting up js with your garbage tacked on type bullshit that doesn't actually work.

>Typescript let's it suck just a bit less
But its a lie. I'd rather live in reality than in a lie.

Because structurally Foo and Bar are the same (same properties and methods, i.e. none) and TypeScript is structural. If you add a method or property for Foo or Bar it will be an error. But if you add the same method / property to both it won't be an error, they still line up.

There's a ton of other bullshit in TS too, like generics being bivariant. Which is fucking insane, why have them at all?

pic related, its you

Attached: literally you.png (856x846, 85K)

>types
strong type system*

but whatever.

>But its a lie. I'd rather live in reality than in a lie.
then do that retard. typescript is basically conflicting with modern js already. it's dead end garbage.

whoa structural typing sounds pretty cool though. sometimes i wish other languages had that

my wife ryuuko is so cute

>You realize OCaml can compile to JS bytecode right?
Thanks, I'll look into it. Kotlin appears to be catching on as a Java replacement, hopefully it gains ground over JavaScript too.

>it's dead end garbage.
The community is eating this shit up, doesn't look like a dead end until / if Kotlin catches on. It probably will. The JS community are a bunch of directionless sheep that pick a new favorite every few years. But why can't we just bypass this one terrible meme and go straight to Kotlin?

Some languages do, but usually you make an explicit structural interface, not a concrete type. Not every fucking type in the entire program is meant to be structural.

Look up bucklescript
OCaml and ReasonML (note, ReasonML is OCaml) can also bring in C libraries and anything else.

You can also just go balls out and do webassembly now, compiling directly to Javac bytecode, bypassing JS completely. You can do this in C/C++, Rust, OCaml and tons of other langs but Rust and C++ are the easiest right now, esp Rust with it's cargo import this pile of dependencies and presto you have webasm.

probably because it's yet another transpiled shitlang load of garbage that fails miserably at working with other js?

typescript at least has the positives of working with jsdoc and js and offering a LSP server for javascript/typescript and it's also all implemented in javascript or transpiled ts.

yea

>probably because it's yet another transpiled shitlang load of garbage that fails miserably at working with other js?
worked fine when I tried it and its type system didn't stab me in the back

>typescript at least has the positives of working with jsdoc and js and offering a LSP server for javascript/typescript and it's also all implemented in javascript or transpiled ts.
not much of an argument when everyone appears to be in agreement that JS sucks

github.com/Microsoft/TypeScript/issues/13756

The short-circuit (literally CS 101) is why it fails.

>dropping existing ecosystem and tooling for yet another flavor of the week transpiled load of shit isn't an argument

just stop jetbrains shill.

dipshit

Try actually implementing Foo and Bar. This only happens because Foo and Bar are both equivalent to {}.

I put it there for clarity you numbnuts, you can omit it and still get the same thing. TS is structural.

typescriptlang.org/play/#src=class Foo {} class Bar{} function ensureFoo(foo: Foo) { if (!(foo instanceof Foo)) { // Should never happen, right? foo must be a Foo! throw new Error(); } } ensureFoo(new Bar());

ok

class Foo {
getNumber() { return 0; }
}
class Bar {
getNumber(): number {
throw new Error('WHAT THE HELL');
}
}
function ensureFoo(foo: Foo) {
if (!(foo instanceof Foo)) {
// Should never happen, right? foo must be a Foo!
throw new Error();
}
}
ensureFoo(new Bar());


Just because things are structurally equivalent doesn't meant they're the same

Attached: V0NljtO-1ZEkgZL1pn5I2hqSA27Tv6Sf9cC7memKgdg.png (1024x739, 937K)

>Just because things are structurally equivalent doesn't meant they're the same

Try implementing Bar exactly the same as Foo. This literally only happens if both types are equivalent to an empty object.

No, it literally doesn't. Here's copy and pasted in the playground. Zero error.

typescriptlang.org/play/#src=class Foo { getNumber() { return 0; } } class Bar { getNumber(): number { throw new Error('WHAT THE HELL'); } } function ensureFoo(foo: Foo) { if (!(foo instanceof Foo)) { // Should never happen, right? foo must be a Foo! throw new Error(); } } ensureFoo(new Bar());

In TypeScript and empty class like Foo{} is equivalent to any. So you basically had function ensureFoo(foo: any) which is why you can pass a Bar without issue.

Try learning something for more than 10 minutes before shitposting with trivial code.

instanceof is a construct from JavaScript, JS instanceof expects a value for the right-side operand.
x instanceof Foo in JS will perform a runtime check to see whether Foo.prototype exists anywhere in the prototype chain of x.
In TypeScript, interfaces have no emit so neither Foo nor Foo.prototype exist at runtime.
Plus you short circuted !(foo instaceof Foo) so compiler optimizes it away and gives no warning.
Now you run it and everything implodes. Language specs are there for a reason, always go over one in detail and note the defined behavior of everything, such as interfaces

>java monkey literally too retarded to understand structural typing

>Wearing shows in bed.

Do all Americans do this?

typescriptlang.org/docs/handbook/type-compatibility.html

See
If the fields and methods line up they are the same. This includes {} but also more complex structures.

>In TypeScript, interfaces have no emit so neither Foo nor Foo.prototype exist at runtime.
They aren't interfaces, they're classes. Concrete structures!

>Plus you short circuted !(foo instaceof Foo) so compiler optimizes it away and gives no warning.
That has nothing to do with it. Read the thread. And then a book.

I understand it, and that's why I hate it. I understand if I shoot myself in the foot I'm gonna end up with a bullet wound in my foot.

My shoes come off at the door, but my roommate wear shoes until he showers and goes to bed. It's one of this nation's greatest weaknesses.

typescriptlang.org/play/#src=class Foo { getNumber() { return 0; } } class Bar { getNumber(): number { throw new Error('WHAT THE HELL'); } } function ensureFoo(foo: Foo) { if (!(foo instanceof Foo)) { // Should never happen, right? foo must be a Foo! throw new Error(); } } ensureFoo(new Bar());

wrong paste?

Making wild claims based on something you have no knowledge of? Sounds like typical Jow Forums.
Typescript makes sense for JavaScript. It is the way it is because it is meant to integrate easily with existing JavaScript code. It has one of the most sophisticated and intelligent type systems. Typescript is one of the best type systems.

How are you going to shoot yourself in the foot with anything other than your contrived bullshit example? Keep in mind any class in Java can also declare that it extends another class and override a method to throw an error.

I meant see

I mean if you want a "real" example I can give you one.

function assertInOrder(set: TreeSet) {
let last = Number.MIN_VALUE;
for (const n of set) {
if (last > n) throw new Error('out of order - should never happen');
last = n;
}
}
assertInOrder(new HashSet(10, 9, 8, 7, 6 /* etc */));


You could imagine TreeSet and HashSet are structurally equivalent. But they mean different things.

Except that would only typecheck if HashSet has all the fields of TreeSet, including private ones.

And what if they do?

Attached: 2201197_1.jpg (630x630, 27K)

TypeScript is fine for the enterprise. You've got assholes who've been working 9-5 as "developers" for the past 25yrs without ever expanding their skillset beyond webforms. Do you want them jumping in head first on your node/react/rx app??? Protip: no, you don't.

My team wrote one of the biggest javascript apps in our city about 5yrs ago when TypeScript was just coming around. As team lead, I needed to guarantee that the shithead "senior devs" who were "senior" because they hadn't applied for a job in 25yrs, didn't mess up. Of course they did. We all did. The app was shit. But it was LESS shit than it would have otherwise been without TypeScript.

As for null, fuck null.

So you went out of your way to copy over every single field in TreeSet to HashSet? This is literally as retarded as complaining that you can have HashSet extend TreeSet in Java, override the getValues() method to be out of order, and complain about the type system not protecting you.

I'm a PHP developer. Why should i learn typescript. i fucking hate javascript and coffeescript and script it's horseshit. I hate PHP too but not as much.

Everybody who reads TS documentation knows that 'foo instanceof Foo' tests whether foo references an instance that was created by the Foo constructor function, but because of structural typing, even when the result is false the compiler can't conclusively say that foo isn't compatible with the Foo type which is why you use user defined type guards basarat.gitbooks.io/typescript/docs/types/typeGuard.html
There's nothing to see in this thread. This is known behavior. Write your own compiler in that outputs TS or straight to JVM bytecode. Problem solved. Call it GNU's Not TypeScript