Add support for duck typing on events #31
Labels
enhancement
New feature or request
Comments
kzu
added a commit
that referenced
this issue
Oct 31, 2022
A new records-based generator emits an __[Type]Factory that can convert from dynamic to the target record type. Observe now adds another Subject that can convert, and we register this subject as compatible whenever the target type doesn't equal the given event. We optimize this scenario by caching these new compatible subjects like we did before. If no converter is available, the event type will just never be invoked in this "duck typing" manner. We offer two conversion mechanisms: the generated factory, and an explicitly declared `Create(dynamic)` method on the record type. This can allow more complex scenarios to still work even if we don't generate code for them. Closes #31
kzu
added a commit
that referenced
this issue
Nov 1, 2022
A new records-based generator emits an __[Type]Factory that can convert from dynamic to the target record type. Observe now adds another Subject that can convert, and we register this subject as compatible whenever the target type doesn't equal the given event. We optimize this scenario by caching these new compatible subjects like we did before. If no converter is available, the event type will just never be invoked in this "duck typing" manner. We offer two conversion mechanisms: the generated factory, and an explicitly declared `Create(dynamic)` method on the record type. This can allow more complex scenarios to still work even if we don't generate code for them. Closes #31
kzu
added a commit
that referenced
this issue
Nov 1, 2022
A new records-based generator emits an __[Type]Factory that can convert from dynamic to the target record type. Observe now adds another Subject that can convert, and we register this subject as compatible whenever the target type doesn't equal the given event. We optimize this scenario by caching these new compatible subjects like we did before. If no converter is available, the event type will just never be invoked in this "duck typing" manner. We offer two conversion mechanisms: the generated factory, and an explicitly declared `Create(dynamic)` method on the record type. This can allow more complex scenarios to still work even if we don't generate code for them. Closes #31
kzu
added a commit
that referenced
this issue
Nov 1, 2022
A new records-based generator emits an __[Type]Factory that can convert from dynamic to the target record type. Observe now adds another Subject that can convert, and we register this subject as compatible whenever the target type doesn't equal the given event. We optimize this scenario by caching these new compatible subjects like we did before. If no converter is available, the event type will just never be invoked in this "duck typing" manner. We offer two conversion mechanisms: the generated factory, and an explicitly declared `Create(dynamic)` method on the record type. This can allow more complex scenarios to still work even if we don't generate code for them. Closes #31
kzu
added a commit
that referenced
this issue
Nov 1, 2022
A new records-based generator emits an __[Type]Factory that can convert from dynamic to the target record type. Observe now adds another Subject that can convert, and we register this subject as compatible whenever the target type doesn't equal the given event. We optimize this scenario by caching these new compatible subjects like we did before. If no converter is available, the event type will just never be invoked in this "duck typing" manner. We offer two conversion mechanisms: the generated factory, and an explicitly declared `Create(dynamic)` method on the record type. This can allow more complex scenarios to still work even if we don't generate code for them. Closes #31
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
One of the challenges in an extensible app is the sharing of the event types that extensions can use. In strongly typed languages like C#, this usually involves referencing a library of such types somehow, and consequently, shipping and versioning become more costly.
This has never been an issue in Javascript or Typescript for example, and VSCode is a clear example where this benefit makes extensibility far simpler. Just "dot your way" into whatever event you're subscribing to, and subscribe by name.
Merq can do better, though. We could allow the ease of use of "copy-pasted event definitions" (similar to what you get by cloning a .d.ts in typescript) with some compile-time code generation to do custom conversion without incurring in any serialization costs. The event type can effectively become the event (full) name, and the type is just used to lookup a custom conversion, should it be necessary at notification time.
From the consumer and producer point of view, nothing changes from the existing API.
But now two libraries can have clones of the same event (record) definition, and notify/observe each other the same.
Initially, we should just support record types (given their typical simplicity) and primitive types for ctor args and properties.
If the feature gets broader adoption, we can expand to full deep-copy behavior.
The text was updated successfully, but these errors were encountered: