Typescript: multiple inheritance?

I have come across a scenario migrating to typescript and octane, where I am having difficulties figuring out the right way in javascript. Pretty much what I need is multiple inheritance as shown below:

project -- private project-------
               \public project    \
                                   \
song -- private song -------- Shareable           
          \_ public song 

So, essentially, I have “abstract” classes (project, song) which exist in two variations: public and private. For instance project would define ED properties and methods that are the same for private and public projects. Then the private and public project classes inherit from project and define additional properties. This all worked fine so far, but now I need to add a second parent class Shareable. The Shareable base class would add methods and ED properties that are required to make a project or song shareable. This would be useful to implement a generic component that allows to share a private entity, by defining the input to be of type Shareable.

Long story short, my issue here is that js is not supporting multiple inheritance and I don’t see a way how I can make this work with single inheritance.

As for the backend, private project is a dedicated endpoint that requires authentication. public project is a dedicated endpoint that does not require authentication. And the result of sharing a private project is a public project.

The problem here is not Ember-specific; as you note:

js is not supporting multiple inheritance and I don’t see a way how I can make this work with single inheritance

In general, I find that reaching for multiple inheritance is nearly always something I’m going to regret later. In cases where it’s tempting, I reach instead for one of:

  • plain-old functions: they work surprisingly well for a lot of cases where people tend to try to use inheritance
  • delegates: define an interface that a property has to fulfill, and then supply it either directly via the constructor or via Ember’s DI system (including services, which are basically just singleton delegates)

In the pattern you’re describing, a delegate seems like exactly what you need. You don’t actually need the things you’re to be properties on the class itself (from what you’ve written anyway), just in some way associated with it, and a delegate is perfect for that.