Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

I'll add a 4th thing to his list based on my experience moving from Java to Typescript:

Nominally-based type systems like Java (where you can only write Foo f = new Bar() if Bar has Foo somewhere up it's static type chain or interface hierarchy) are way more of a pain in the ass than structurally-based type systems like TypeScript (where you can say f: Foo = new Bar() as long as TypeScript determines Bar has all the required fields of Foo).

Primarily this makes refactoring much easier because you don't have to necessarily change things up a (potentially brittle) type hierarchy. Instead, you can just add new properties to your type to fulfill the set of properties required on the target type.

View on HN

That isn't always a benefit, though. When interfacing with a database schema that uses small integers for ids, I'm all the time defining types like `struct CustomerId(u32)` and `struct InvoiceId(u32)`. It's incredibly valuable that the compiler will not let me mix up a customer and an invoice, even if both of them are 42.

Ad hoc and structural polymorphism can coexist. You can define an object that contains a customerid and an invoiceid, and they won't get mixed.

In the end when properties are missing I usually use an interface and click "Implement all missing fields and methods" anyway. Modern Java would be good enough for solving this problem.

I could agree that error message with information which properties are missing would be helpful is some circumstances.

This is why interfaces exist.

Nominally-typed interfaces are still clumsy in some circumstances. For example, if I consume a library with

    namespace ThirdParty {
      public sealed class Foo { public void Do() { } }
    }

and I want to hide it behind

    namespace MyCode {
      interface IFoo { void Do(); }
    }

the compiler does not accept ThirdParty.Foo as an implementation of MyCode.IFoo so I must define a wrapper

    namespace MyCode {
      sealed class ThirdPartyFooAdapter : IFoo {
        public ThirdPartyFooAdapter(ThirdParty.Foo instance) {
          _instance = instance;
        }
        readonly ThirdParty.Foo _instance;

        public void Do() => _instance.Do();
      }
    }

which only gets more tedious as the number of methods and implementations grows.

While I agree, I feel that third-party library consumption is a bit of an edge case (i.e. the majority of your interface implementations won't be wrappers around third-party stuff).

Whenever I do work closely with a third-party library, the wrapping pays for itself quite quickly because it never takes long for you to find a 'quirkiness' or unsuitability in how the library implements something and you end up with code resembling this:

   public void Do() {
     _instance.SpecialOptionForTheBehaviourYouRequire = true;

     try
     {
       _instance.Do();
     }
     catch
     {
       // Workaround for bug that has not been fixed in ThirdParty Library yet. Remove when fixed!
       _instance.ResetBrokenStateCausedByBug();
       _instance.Do();
     }
   }

Reply on news.ycombinator.com