SLUGs Meeting on December 6th

[styrum]

John. No disrespect, but please Google "Argument from authority".

[styrum]

I have no confusion regarding these matters. Even if you have a "pure" command pattern (because it is good enough for the purposes of that piece of code) that can only accept and execute "commands"(messages) in a "one message corresponds to only one action" manner, with no state dependent branching in the actions, it is a state machine already, with just one state and as many possible "events" and exactly the same number of actions as the total number of possible "commands". Of course, in that case it will be an obvious overkill to use code capable of handling multiple states (only if you are absolutely confident that you will never need state dependent code there!). But that doesn't change the fact that this pattern can still be viewed as a (degenerate, single state) state machine. Therefore, an actor in NI's AF is always a state machine.

[styrum]

As far as "easy extension and modification" are concerned I advise everybody to try to fully implement at least the "one way decoupling" ("zero coupling") example (an abstract message class in the nested sender actor with only Send method implemented and a concrete message inheriting from that abstract one in the receiver caller actor with Do implemented) and then try to add (delete) a member to(from) the data of that message. You will have a lot of fun trying to make everything work again after that "simple extension/modification".

[jlokanis]

Not sure if you realize this but every time you edit your post after it is posted causes a new message to be sent out to everyone on the forum.  Maybe try proofreading and making changes to your response before hitting the post button to cut down on all the spam.  One of the last replies you posted resulted in 11 different variations of the post being sent out to everyone.

---

@styrum wrote:

As far as "easy extension and modification" are concerned I advise everybody to try to fully implement at least the "one way decoupling" ("zero coupling") example and then try to add (delete) a member to(from) the data of the message sent from the nested actor to the caller. You will have a lot of fun trying to make everything work again after that "simple extension/modification".

---

I do this all the time.  I simply need to edit the message class and then update the concrete method in the receiving project to utilize the new data member.  Then I open the sending project and update the call where it constructs the message.  Trivial.

The issue that harder to correct is if you name a class one thing and then change your mind later.  Or worse yet if you decide to move it to another location on disk as well.  But that goes for any LVOOP code, not just message architectures.

[styrum]

Oops. Sorry for multiple edits. Just want to make my comments as clear as possible that way. I will try to cut on the number of edits.