Hacker News Reader

Comment by slackingoff2017 | Hacker News Reader

slackingoff2017

>It should be entirely possible for me to construct an object that fits the definition of a frog without specifying I'm creating a frog.

This is known as structural typing and TypeScript does exactly this. Two objects with the same properties are the same.

This usually works well, but there are a few issues with this. Number one is related to optimization. The type system that results from using structural typing is unsound. This doesn't matter for typescript since it compiled down to JavaScript which has no types anyways, but for a typical VM executed language there's many optimizations the compiler can't do.

The second issue with structural typing is what I like to call the "mixin problem". If you get too flexible with composition it becomes close to having no type system at all.

View on HN

Is it true that all structural type systems are unsound? I was under the impression this is a typescript specific problem.

I tried to find the answer and it seems the problem is much more complex than I thought. Rather than bullshit about it I'll just say I have no idea :)

Is structure defined just by type?

Like is all things which only have two integer properties considered the same?

{ Int age; Int weight; }

Would be equal to:

{ Int x; Int y; }

Close, any objects with the same properties and types are compatible. The name of the properties and their types need to match.

And this isn't always a good thing. If you have a function dealing with the property 'length' or 'value' for instance, you might as well have no type system because Typescript will allow you to pass in any object with those properties which is almost anything.

While the code will still compile and run like this the type system has failed its purpose of preventing developers from using the wrong types.

I see, sounds interesting. Are the names namespaced? And how would a method know its compatible? Do you type the properties a method needs instead of the object name?

You pretty much act as you do with regular type systems, rarely creating types that are compatible by accident. There is one place however where you use structural typing constantly.

TypeScript is a superset of JavaScript and using "options" objects as method parameters is a common pattern. These options objects are synonymous with anonymous classes and don't have a name, only a shape. Structural typing is one of the strategies TypeScript uses to maintain compatibility with patterns in JavaScript that use these nameless objects.

There are no namespaces. Methods are compatible if they take the same or a subset of the parameters. Objects need to have matching property names and values.

Hum, thanks for the info. I feel curious to try it out. I think names should be namespaced though, that could solve the issue of having a length or value named property. The namespace could distinguish between two values that aren't compatible for example. Though I guess if the types are precise enough, they could embed some of that.

Given an object with a length property with the type a method expects, is there ever a scenario where the method is incorrect?

I'm trying to wrap my head around it: if a method needs only the length property, which is an unsigned int, is there any good reason why it shouldn't accept any object that has that property?

It appears at first that this is a good quality: the code is general whilst obviously avoiding any type errors, including null/undefined errors.

The type system is still working properly in that it will produce code that compiles and runs. For the developer such a behaviour can be misleading. This is compounded by IDE's with intellisense which will suggest passing random objects with the correct properties into the function.

Reply on news.ycombinator.com