Hacker News

Typescript had to support JS's quirks... :/

   class Foo {
      public bar = 1;
      private _value = 'hello';
      static doSomething(f: Foo) {
         console.log(f._value);
      }
   }
   class MockFoo { public bar = 1; }
   let mock = new MockFoo();
   Foo.doSomething(mock); // Fails

Which is why you'd generally use interfaces, either declared or inline.

In the pointer example, if the long field is private then it's not part of the public interface and you shouldn't run into that issue no?

seanmcdirmid 5 days ago [ - ]

_value is part of the type for Foo, it’s as if it was a public field. You can forge a reference to Foo by adding _value to your mock. TS deals with private fields by pretending they are public when it comes to matching. There are more rigorous ways have hiding and then revealing private state in structurally typed languages, but they involve something that is suspiciously like using a name, and really, it makes sense. The only way you can hide something and recover it later is via some kind of name (unless you can somehow capture the private structure in a type variable so it’s just passing through the parts that can’t see it).

You can do a lot just by hiding the private state and providing methods that operate on that private state in the type (using interfaces for example), but that approach doesn’t allow for binary methods (you need to reveal private state on a non-receiver in a method).

b_e_n_t_o_n 5 days ago [ - ]

Can you explain the last part more? I don't think I'm grasping what you mean.

seanmcdirmid 5 days ago [ - ]

You can deal with receiver private state since you are exporting methods on the receiver as part of your type signature. If those methods are called, the receiver can see itself, structural typing works fine and you still have encapsulation. Eg

    interface Foo {
      fun doFoo()
    }

You can call doFoo() on some value, and that value can refer to its private state that doesn’t appear in Foo.

However, if you want to see the private data of an argument, private data has to appear in the signature (or use nominal typing). The easiest example is an equality method that compares private state.

    interface Foo {
      fun equals(otherFoo: Foo): Boolean
    }

The receiver of the equals call can still refer to its private data, but whatever you a provided for otherFoo is only guaranteed to have the equals method. You might be able to deal with this isn’t an opaque type:

    interface FooModule {
      export type t
      fun equals(foo: t, otherFoo: t): boolean 
      makeFoo(): t
    }

But you really aren’t doing structural typing anymore, and basically are using t like you would a name.