On Tuesday, 5 June 2018 at 13:33:18 UTC, Kagamin wrote:
Why message detection is in receiver instead of infrastructure?
Because recursion. One of the messages I've written is a wrapper message for a multi-packet split message, and calls receive with the reconstructed byte buffer. Fairly elegant way to not special-case the thing that much.
And why not gather message types from receiver's interface with DbI (like WCF does)?
There already is design by introspection. But I don't parse a type, I parse an entire module. The switch statement is being built through the results of an introspective pass.
This is quite deliberate. I'm writing a large-scale maintainable codebase. Having everything in one file is a sure way to reduce maintainability and thus productivity of the programmers maintaining it. Getting D to favour lots of smaller files means getting creative.
I *could* put all the messages in an interface and inherit from it... but that's a fairly old-school way of thinking. I don't need a giant virtual function table to enforce implementing message types when I can use outside-the-box introspective tricks and compile down to nothing.
There's also a design advantage to going message-first here. I'm forcing the maintainers to think of the data before they get to implementation. The existence of a struct already explicitly creates one piece of data - the message ID. Anything else you put in there is up to you. And being structs, means that you don't constantly have to maintain function signatures each time you want to add a value to a message for example.
