Improve ergonomics of creating self-referential actors

[piegamesde]

Context: https://github.com/idanarye/woab/issues/15#issuecomment-813472538

I'm using the first proposed solution, but it's not pretty and it doesn't scale well. As soon as you introduce a third dependent actor into the equation things start to get really ugly. I think it wouldn't be bad to hide that ugliness behind an abstraction that supports this use case better.

[piegamesde]

Not sure if a good idea, but one could use type level magic to allow code like this:

let (addr1, addr2) = (Actor1, Actor2)::create(|(ctx1, ctx2)| {
    …
    (Actor1 {…}, Actor2 {…})
});

(One could replace the type level magic with index fuckery by using lists instead …)

[idanarye]

Note that this is an Actix problem, not a WoAB problem. That code example is 100% actor handling and 0% GUI. So the solution should be in Actix, not here. And I've actually PRed the solution to Actix: https://github.com/actix/actix/pull/491. This is non-hacky version of second solution I proposed in that comment. You can see a usage example in the master branch docs, but you'll have to wait for the next Actix release before you can use it. I'll probably have to do a WoAB release too, but this I can do quickly as soon as they make a release.

In the meanwhile, just use the original hacky version of the second solution. You can always make a helper function to hide the hackyness away.

[piegamesde]

Oh that's totally awesome, many thanks! However, I won't wait until new releases and simply switch to some nightly commit (long live Cargo's great dependency management).

[idanarye]

Funny enough - WoAB uses Actix version ^0.11 so once Actix releases 0.12 you'll have to wait for a new WoAB release - but as long as you use a nightly commit that's still technically a 0.11.1 it should be compatible with WoAB? I think? At least as far as Cargo is concerned - any 0.12 changes that break WoAB will have to be introduced in some nightly version before 0.12...