chore: rewrite api

[hseeberger]

No description provided.

[jrudolph]

Somewhat of a feat to get that working, I guess :) I consciously stayed away from such a solution because of what I suspected it would get me into.

I'll list some pros and cons from my perspective (comparing to the mechanism I suggested):

Pros of this version:

• in some twisted way more idiomatic Rust than adding extra reply parameters
• more type-safe in edge-cases (the reply parameters left some highly theoretic room for constructing wrongly typed replies)

Cons:

• Can EntityRefs be passed around at all any more because of the complex types? This is notably missing in the tests. Can you show a struct or function definition using such a type?
• more complicated types, more boilerplate needed (for marginal benefits? i.e. slightly more idiomatic and slightly more type-safe)
• The definition of an entity (command, events, handlers) now becomes distributed over the different command impls. This makes it harder to get a full picture of the functionality of an entity.
• tries to work around deficiencies in Rust's enums by opening up the Cmd type hierarchy and then closing it down again with type-level trickery (as you know I come from the same thinking wrt static typing but becoming more and more fond of simpler pragmatic solutions than perfect ones)
• (this was also the case before but) interface and implementation are tightly coupled. Now it's even harder than before to provide multiple implementations for the same (cmd, reply) interface.

In total, most of these points might be reasonably acceptable. The main blocker for me is whether the EntityRef type is still usable at all (or how it can be made so).

[jrudolph]

Will these types never end up in user code? How do you pass around these refs if you cannot reasonably type them out any more?

[hseeberger]

EntityRef<Uuid, Evt, Counter, Decrease, Cmds<Increase, ()> is how this type looks like in the example. I agree that this is ugly, but users can make a type alias once. And I plan to create a type macro which can be used to ease making the type alias, something like:

type CounterEntityRef = EntityRef!(Counter, Uuid, Evt, Increase, Decrease)

[jrudolph]

👍 indeed, that's not too bad, a bit weird how the list of commands needs to be encoded, but maybe ok enough? Is there an implementation of a coproduct in Rust which we could reuse?

[jrudolph]

frunk has a coproduct

[hseeberger]

Neat, will give it a try.

[hseeberger]

Looking good.

[hseeberger]

Actually to define the entity, there is not more boilerplate. The examples written in the new way have about the same number of lines of code, including the now possible individual errors and replies. And here comes the best: You can still apply the old style by just defining a single command (enumeration).

[jrudolph]

Actually to define the entity, there is not more boilerplate. The examples written in the new way have about the same number of lines of code, including the now possible individual errors and replies. And here comes the best: You can still apply the old style by just defining a single command (enumeration).

True, the old Eventsourced style also had its drawbacks. The new style feels a bit like implementing commands the OOP way which is workable but maybe not what you would expect when you also have pattern matching and enums in the language.

[jrudolph]

pattern matching and enums in the language

frunk::Coproduct has fold which offers pattern-match-y syntax:

fn handle_stringly_things(co: Coprod!(&'static str, String)) -> String {
    co.fold(hlist![
        |s| format!("&str {}", s),
        |s| format!("String {}", s),
    ])
}

[hseeberger]

True, the old Eventsourced style also had its drawbacks. The new style feels a bit like implementing commands the OOP way which is workable but maybe not what you would expect when you also have pattern matching and enums in the language.

Wait until state becomes more (an enum) than a simple struct (like in the Counter example). Then you will get your pattern matching ;-)