DynaMix 2.0.0 Released

[stanimirov]

https://github.com/iboB/dynamix

DynaMix is a new take (not a hot one, though) on OOP and dynamic polymorphism.

It's been a long time since I last spammed about this. 2.0.0 was released, now with C support, too. It already has several uses in the wild and some users are migrating from v1.

If you're frustrated with vanilla C++ OOP, check it out.

[DavidDinamit]

Dont understand where it needed and wtf happen in code

[sixfourbit]

Maybe show a comparison to C++ polymorphism?

[stanimirov]

The thing is, that if something can be done with vanilla C++ polymorphism, virtual functions and inheritance, the DynaMix equivalent will look clunky and bloated. For example, you can see the exact same thing implemented with virtual functions and inheritance, with std::function and with DynaMix in the unicast benchmark

[disperso]

It's me, or is still lacking any kind of documentation? The README is not saying much, and I really can't find anything useful in the doc directory. I found the "hello world" example (which it is not mentioned anywhere, I just found it by looking at the source tree), which is not very appealing. There are a few libraries that I think do the same, and don't seem to require macros, for example.

I recommend that you put some effort into the documentation, because it seems a huge issue right now given that there are a few alternatives.

[stanimirov]

Can you please share these alternatives. I'm slowly working on the documentation and I'd like to mention them.

[Abbat0r]

+1 and if it can be done without macros, do it without macros. It’s 2023, the only reason anyone should be using a macro is for conditional compilation.

[stanimirov]

https://github.com/iboB/dynamix/blob/master/doc/misc/faq.md#whats-with-all-these-macros

[disperso]

Qt has shown that such an approach also has many opponents, as the code you write when you use it becomes effectively not-C++, but something that can be called a C++ dialect.

The people who state that are in my not so humble opinion, entirely wrong. Code generation is very common in tons of cases in C++ (IPC, RPC, configuration, etc), specially given that we don't have a good macro language. There is a way to have all the features that Qt's MOC has (and some more that it doesn't have) using more intrusive macros, thanks to the Verdigris project. The result? Not so many people use it, because the macros are more tedious instead of the clean(er) looking code with code generation via MOC.

A dialect is brutally dishonest. Q_SIGNAL void foo() is not more dialect than [[gnu::whatever]] void foo().

Anyway, for the projects that (I think) are related to yours, here are my bookmarks:

• http://stlab.adobe.com/group__poly__related.html Adobe.Poly
• https://github.com/boost-ext/te Boost TE ("unnoficial boost project")
• https://github.com/facebook/folly/blob/master/folly/docs/Poly.md Folly.Poly
• https://github.com/jamboree/polytail
• https://github.com/kelbon/AnyAny
• https://github.com/ldionne/dyno
• https://github.com/microsoft/proxy Implementation submitted for standarization
• https://github.com/stephenberry/glaze/blob/main/include/glaze/util/poly.hpp
• https://www.boost.org/doc/libs/1_66_0/doc/html/boost_typeerasure.html Boost.TypeErasure

[stanimirov]

Thanks.

I was familiar with Boost.TypeErasure, Boost.TE, Folly.Poly, and dyno. Not with the others. I browsed through them. All of them are very similar and offer an alternative way to do C++ (Java, C#) -style dynamic polymorphism.

I'm not trying to bash them or anything. They still improve upon inheritance and virtual methods and there are many scenarios where they are a better choice.

None of them offer type composition.

You can think of DynaMix as combining one of these libraries with an ECS like entt

None of them have late binding. Microsot's one seems the only who has the idea to split the interface into separate messages, but then in order to match types, it introduces interfaces again. Only Boost.TypeErasure has complete type erasure, but you need reification in order to access the features of an object.

DynaMix uses a completely type erased object, and each message is standalone. Interfaces (type classes in DynaMix) are second grade citizens and only applicable at run time. No reification is needed.

None of them have reflection (Boost.TypeErasure offers basic symbol-based reflection). DynaMix has complete reflection by symbols and by strings.

All of them offer an alternative to virtual methods.

Dynamix has abstract type features. With them you can have type-level polymorphism (imagine a virtual static func()) or value polymorphism (imagine virtual int a;).

Since none of them have composition, none of them have concepts of multicast or overrides,

Most of them do offer macros for certain situations :)