Implementing the State Pattern in Actor Framework

[crandiba]

Hi dostini, all,

In case this is useful to anyone going down this path, please find a small comparison of the two solutions discussed: Actor "is in a state" vs Actor "has a state".

@dostini: thanks for the response; in case it helps, here's how I'm going about it:

I'm starting from the initial solution where the States are children classes of a given actor. In this case we follow a  normal AF workflow, save for a "Copy Data" method that must exist when a state change occurs to pass any data over to the next state. I admit this remains as a burden to the developer and somewhat strikes me as a loose end, but I'll let it go for now.

However, when we try to expand the Actor through another Child Actor, here's how I dealt with it:

Given two Actors, ActorX and ChildOfActorX, step one is to place the code/functionality in a dynamic dispatch VI of ActorX. Then, create a VI for override in the corresponding State (for example: STANDBY state creates an override of the "action.vi". By default, the only thing there is the "Call Parent implementation" primitive. 

And now it is from this vi (the States:STANDBY.lvclass:action.vi) that we will create the AF message.

This way the message still enforces that not only the correct state will execute the action, but also that multiple states can, which I found lacking in the other approach as there is no common parent for the states (other than the base state of course, which will not carry specific functionality). By having the functionality in ActorX, ChildOfActorX can now override it easily if needed. 

I tried to get it down in this draft, if I can clarify this for anyone please let me know.  I'd also like to hear @CaseyLamers or someone else that has tried the other approach as I'm afraid I might be missing something here.

Thanks again,

Cris

[crandiba]

Hi all,

I am not quite sure where to post this, so here goes. 

Recently I posted here about how to cope with copying the parent data from one object to another when changing state. My motivation comes from the following> if the pattern is used as part of a framework, I would like this to be taken care of, and not have to update the accessors in that Substitute Actor.vi every time the class data changes. 

So I started to have a look if it was possible to have an accessor that adapts to the class data and does just that, copying the parent data over to a new object. 

I know this gets sensitive now, as we've all seen the discussions regarding this, as well as some serialization related ones (flatten class data to xml, AQ serializer, malleables as accessors, etc.)

As it turns out, there is an admittedly not very elegant (but somewhat creative, I find) way to do it. Although malleables cannot be used, the Type Specification structure can be used outside of a Malleable. This coupled with some manually use of the Bundle/Unbundle function lets you have the wiring done beforehand and adapts to the class data upon any modification.

What I was really looking for was a Paul Cardinale style Xnode, but until then I wanted to share with you this method. 

In the case of descendant classes, it will copy over the common ancestor data, as you would expect. Drawback is of course its limited to the number of elements you have statically defined in the bundle/unbundle terminals.

I know its far from perfect, but hopefully it can raise a discussion and lead to a better way of doing this. In my view, it will then lead this pattern to become much more appealing, as it can then be used as a basis for a framework.

[code-lux]

When I try to install version 1.1 in LabVIEW 2020 I get an Error from VIPM: Main Package Name: NI State Pattern Actor v1.1.0.10 Package Name with Error: NI State Pattern Actor v1.1.0.10 Error Message: VIPM could not install the package ni_lib_state_pattern_actor-1.1.0.10 . Error Code: 8 Error Source: Öffnen/Erstellen/Ersetzen einer Datei in 73A5BDB5DE39A116FCA8B48EECAF417C->64F66CF17BFDEECFC99D007FAABFE022->1C3783F9D899991C78D90B278C93351B->4F9E61CEDBE6910285FE1211530F26A8->96DC0328B56514F73D2FABBD74865399->OGPM Class.lvlib:9379CFD8CA331CF0E38A98FA9D7316C6->OGPM Class.lvlib:D5B6EB965D0BC09274E3E5144188318D->C816626B524CF3DD3AA4372A60C7FF8E->VIPM Main Window.vi C:\ProgramData\JKI\VIPM\cache\ni_lib_state_pattern_actor-1.1.0.10.spec ===============

[Oli_Wachno]

I have installed StatePattern Actor three or four weeks ago on a clean new LV2020. Haven't seen any issues so far.

Do you have sufficient disk space? 

Do other VIPM packages sintall correctly?

[justACS]

The students in my current AF class just downloaded and installed the package from VIPM without issue.  It's a virtual class, so they are all in their own environments.

The current package build is fine.  You'll want to look at things like access rights on your own machine.

[Taggart]

Look on the VIPM forums. 

https://forums.vipm.io/forum/5-vi-package-manager-vipm/

If I remember correctly error 8 has something to do with permissions.

[code-lux]

When I ran VIPM as Admin it installed nicely on LV2020.😀

@justACS it would be helpful if you could add the hint to Admin rights to the description.

@JKI it would be nice if VIPM would be more helpful for these basic problems.

Meanwhile I programmed my states differently by putting a Child Class of a State Class into Private Data of my Main Actor for each State... it´s clean but I´m not sure if I can reach the same level of functionality as with State Patern Actors.