Hacker News Reader

Comment by qwertyuiop924 | Hacker News Reader

Dynamic property addition is super useful.

With the == vs === thing, I think you're confusing dynamic typing with weak typing. Weak typing is why == and === exist, and it totally sucks.

>I'm looking at a function parameter in a random file. How do I even begin to work with it?

First off, Duck Typing: The type of the parameter is the intersection of the types the functions it is called with contain.

Secondly, this is why you document your code and choose prescriptive variable names. Honestly, this is pretty bad even with types (the first question I had when I looked at my first chunk of real world C was, "what the hell is the variable 'int rv;', and what's it being used for?).

Even I'll admit that type annotations can be useful sometimes, but I don't need them.

View on HN

Having a parameter 'user' doesn't infer what properties are on it. If you're going to document what properties it has you might as well create a type definition for it.

Duck typing (or checking types at runtime) is verbose and forces you to handle type mismatches at runtime. Which means you will probably end up throwing an error anyways when types end up missing the properties you expected.

If your code relies on properties added dynamically that might be useful for you, but god help anyone working with your code.

Well, obviously, I wouldn't document everything, but if the argument name is "user" and it's an object, as opposed to a string, than it's probably a user object. Not exactly rocket science.

That's not exactly what Duck Typing is, but that is possibly true. However, in an OO system, Duck Typing has massive benefits, as you don't have to depend on inheritance to see if an object can be passed to a function: polymorphism. This is the sort of thing Java's interfaces do, albeit clumsily.

>If your code relies on properties added dynamically that might be useful for you, but god help anyone working with your code.

Obviously, you have to be careful about it. But if you're marking nodes on a graph, or attaching metadata to a function, especially if it's temporary, it comes in handy.

You can totally simulate duck typing with Typescript, since it (only) supports structural typing. If your method only expects an object with an asString() method, you can do something like:

    function useAsString(foo: {asString: () => string}) {
        ...
    }

Note that the type we give for foo here is an anonymous type (though this would also work with an explicitly named type).

And now you can do this:

    interface SomeInterface {
       name: string;
       asString: () => string;
    }

    let bob: SomeInterface = { name: "Bob", asString: () => "Bob" };

    useAsString(bob);

And this works, because the interface SomeInterface has an asString() method. No inheritance in sight.

Huh. Pretty cool. Are the interfaces Go-style (must you declare a class/object as that interface, or is it just detected)?

Because if it's not, than it's not duck typing, is it?

Interfaces in typescript are implicit, or auto detected. You dont have to say that a class implements an interface, if it has the correct properties it automatically fulfills the interface. It's like type safe ducktyping and it's super awesome.

That's just compile-time verified duck typing.

Not bad.

Static weak types

No, because you're not doing implicit type conversion, which is what weak typing implies.

Sounds like it works just like Go-lang, then.

Is there a way to cast something anonymous, just a value read in from JSON, to such an interface? This would allow you to specify an important subset of things that an object needs to do, verify it in one place, then pass around the interface handle to anything that needed the underlying object in that role. Presumably, if the incoming object lacked the desired attributes, the "cast" would blow up sooner, during the assignment, rather than later, when the interface alias was used.

Reply on news.ycombinator.com