Well _actually

[energizah]

Hey Glyph,

I'm a big fan of this library. I'm noticing that there's a certain pattern which makes me wonder about an API, and I'm curious to hear your thoughts.

The docs have an example like this:

connected.upon(send_message, enter=connected, [_actually_send_message])

which uses the _actually_send_message method. It reminds me a bit of marshmallow's pattern of field.serialize() calling field._serialize() and similar inheritance-oriented APIs. The common _actually_* naming convention makes me wonder if there should be a real namespace for these implementations

outputs=[mm.actually.send_message]

or mm.impl.send_mesage.

I'm interested if you've had this feeling or how you've dealt with the proliferation of _actually methods.

Cheers.

[glyph]

I'm a big fan of this library.

Nice of you to say so!

[glyph]

I'm interested if you've had this feeling or how you've dealt with the proliferation of _actually methods.

I've definitely felt it's a bit awkward to be cramming everything into the flat class namespace, when really only the input methods need to live there, and the outputs and states all want to be private.

I'm curious how you'd structure such an actually namespace - how do you get things into it? Keep in mind I don't want to confuse IDEs and type-checkers any more than automat already does.

[glyph]

I think that #137 changes the structure so that it is much easier to avoid this sort of naming. There's still some level of duplication, you've got input protocol methods and you've got behavior implementation functions, but they can just be named the same thing now since they don't need to exist in the same namespace, so you don't need to mangle them with conventions like "_actually".