Mixins for Civet about civet HOT 3 CLOSED

@lorefnon I agree that class factories are an elegant and easy way to implement a mixin style. Just that they miss one thing: Constructors (and respective call hierarchies).
This is the one reason why I implemented a dedicated mixin library back in the coffeescript days.

Decorators did not even exist as proposal at that time. I think that they would provide a cleaner integration, I agree.

Maybe I would give it a try and port my library to be based on decorators. I just wonder how the type system can be informed about additional supertypes introduced via a decorator. Any ideas on that?

from civet.

Hi, thanks for the feedback!

A primary goal of Civet is to stick to JS semantics as much as possible. In the case of mixins we'll probbaly converge on ESDecorators when/if it becomes a standard. Civet currently supports decorators using @@decorator syntax (a single @ is ambiguous with class static fields and methods currently).

Thanks for sharing the code sample it looks pretty close to the direction that JS/TS is heading with decorators and I'm always happy to find inspiring ways to make syntax nicer.

I'm glad you like Civet and hope that it will make your wildest dreams come true.

from civet.

Besides decorators, a common pattern for mixins in ts is to use a function that extends an input class (Real world example).

Using this pattern in civet, the linked example (abbreviated) would look like:

UUIDentifiable := Base ->
  class extends Base
    id()
       @_id ?= randomId()

AutoUUID := Base ->
  class extends Base
    uuid()
       @_id ?= randomId()

class Named extends Mixin {}

class TestClass extends UUIDentifiable(AutoUUID Named) {}

which imho is not too bad

from civet.