search

glyph / automat

Self-service finite-state machines for the programmer on the go.
MIT License
583 stars 64 forks source link

Well _actually #112

Closed energizah closed 1 month ago

energizah commented 5 years ago

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 commented 5 years ago

I'm a big fan of this library.

Nice of you to say so!

glyph commented 5 years ago

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 commented 1 month ago

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".