Improve or remove ChannelPlurality?

[simbleau]

I'm not sure if anyone would agree, but I see the plurality as an ergonomic papercut on API usage, especially in Bevy.

commands.open_socket::<MultipleChannels>() and commands.close_socket::<MultipleChannels>() require generics, etc. which doesn't feel at all right.

I don't want to remove the SingleChannel API, since I think it's very helpful.

Perhaps the solution would be to make different traits that can be imported for Bevy?
e.g a ComplexSocketExt trait and a SimpleSocketExt which assume the plurality?

[johanhelsing]

I'm still not entirely convinced that the command extensions are a good idea... even though I think it was I who suggested it. It limits the API to a single socket, allows calling close_socket when there is no socket, what happens when you open and there already is a socket?

Operating on Resources/Components isn't much more complex and makes it a lot more flexible and makes it more understandable what actually happens?

[simbleau]

Yeah, I agree.

[simbleau]

Ok, let's remove the Command extensions for now. I agree with the resource-driven approach.

re: generics, are we expecting users to do something like this, assuming they want to stay DRY?
I'm still not totally satisfied with it, but I'm ok with it.

type MySocketType = MatchboxSocket<SinglePlurality>;
...

app
   .add_plugins(...)
   .init_resource::<MySocketType>();
...
   .remove_resource::<MySocketType>();

[caspark]

Oh hey, I raised a PR for removing the Plurality business over at #468 , without actually realizing this issue exists - that's what I get for jumping straight into PRing before skimming the open issues :)

Re the command extensions: I used the bevy example to figure out how to get matchbox going in my macroquad game, and purely from that angle I would say that yes, I also think the commands are more confusing than they are convenient.