Simple tutorials for complex subjects

[Ethan]

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.