Rosenblatt: Biddlecome: it also has type inference

Saffell: Biddlecome: it does only local type inference

Garfield: External libs require type definitions *.d.ts

Coverton: I haven’t really checked it out in a while, sounds kinda lame though

Monsen: In flow you just have to type function arguments and it figures out the rest

Caligari: Biddlecome: the idea of attaching types to external things is very neat for a gradual type system. But I’m not sure if the boundaries in TS are the best ones.

Lother: Flow’s inference isn’t thaaaaaat great either. It ends up with a lot of unions if you leave the types out

Niesent: Biddlecome: i said that TS has type inference

Johnosn: No definition files; you can define interfaces if you want, but it’ll generally figure them out

Finch: Seikho: TS’s type inference algorithm is horrible though

Hesby: Spotted this in the wild, from our juniorish front end dev: button cl***=”sort-btn not-btn”Sort By:/button

Ebner: Its not supposed to be a button

April: Infernu would be cool if it was backed by a major corporation.

Tunget: Seikho: it only does local inference, and TS has subtyping without occurrence typing, which makes it impossible to have better type inference.

Balderrama: H1input type=”not-input” readonly style=”outline:none;border:none;display:inline” value=”Hello”/h1

Cheslock: Hey guys, so I’m setting a prototype of the object Product – and I’m having issues accessing the actual value of the ‘Product’ value

Amante: Seikho: in Flow, the type system can figure out “reasonable” types for all of your program, without you needing to write a single type. But Flow ends up with a lot of unions, which might not be as good.

Moorhead: Wondering how I can access the ‘Product’s object data

Bultron: Seikho: in Infernu, you get Hindley-Milner inference, which is basically the best one around. But the type system is more restrictive than Flow’s.

Jesko: Seikho, Dolby is an expert on compilers and type systems

Surran: The kicker is the proto is an object, so Product.prototype.rules = { myFunc : fnc{.}} – Wondering how I can access the product’s object data from within myFunc

Eppinger: I wouldn’t really say I’m an expert eh. Just a curious person.

Tautuiaki: So you can generally trust her claims

Pattum: Biddlecome: i don’t trust any claims without a reasonable argument

Hoyt: Boar, this points to the instance in methods

Stains: This is why i’m not a fan of blog posts

Raub: So .what? Flow ES6 TS?

Souvannarith: Raub: it really depends on what you care about. Flow and TS have very different tradeoffs.

Schmoyer: They’re two very different type systems too.

Lachapelle: Raub, use TS if you need types now; but I’d go with ES6 and you can add flow in later as it matures

Sorells: It’s designed to be introduced to existing code as easily as new projects

Raub: They told me to choose one, still pretty new to this world lol, thanks

Zachary: Biddlecome: Aye, so I want to be able to access the parent ‘This’ within the Product.prototype.Rules = { myFunc{.} }

Peyer: Boar, it doesn’t work like that, but you should only have functions on the prototype

Raub: What do you usually do Dolby? Just choose the best tool for the job, but what is that usually for you?

Mateen: Boar, can you show your code in paste?

Ornelaz: Why is subtyping bad?

Kamakea: Raub: with JS? I just use Sweet.js for now. None of the existing type systems for JS have the features I need to write programs they’d need to be at least at PureScript’s level: row polymorphism and higher-kinded polymoprhism.

Steinau: Tcsc: you can’t do global inference with subtyping. And variance is too complicated. Row polymorphism solves the problem of OO things better, imho. Type Cl***es capture families of things in a better way too, imho.