SIMPLE Object Based Framework

[smi38]

Hi all,

My concern is about object based framework.

I'd like to talk about this "sensitive" subject, which divides people around me.

I'm sure there are a plenty of objects aficionados here.

A few years ago, LabVIEW give us the first object based template : the Actor Framework, which is certainly powerfull

...but just UNREADABLE !!!!

When I conduct Core3 training, I'm tempted to show what could be an object based framework in LabVIEW, then I remember how the actor framework looks, then I decide to make my trainies continue to use LabVIEW, and finally I don't show the actor framework.

When will NI provide a SIMPLE object based framework in the TEMPLATES ?

Something like the command patern exposed here by Elijal Kerry :

https://ekerry.wordp...ur-life-easier/

or in a the test executive example of the PTP sequencer :

http://www.ptpartner.../ptp-sequencer/

I still use the "old" QSM (please Daklu, don't bite me), for sure it is not an ideal solution...

I love objects, I used them a lot in my code, but not currently for my high level code.

Any links or suggestions ?

Thanks,

SebastienM

CLA

[mikeporter]

I hacve been poking this idea with a stick for a while myself, and I'm not sure but what the phrase "Simple Object-Based Framework" isn't an oxymoron of the first order. But I agree with you that the Actor Framework stinks on ice. It is overly complex and essentially unreadable. Personally, object-orientation should be a tool in our toolbox that we use when its appropriate and not use when it isn't.

Frankly though, the computer science seems to have gotten over the object oriented fad and is moving on to other things like imperitive programming and functional programming. In fact Carnagie Mellon has made the decision to not even offer classes in object oriented programing to lower-level CS students.

Mike...

PS: About that "stinks on ice" comment, that's just between us right? Nobody else was listening right?

[smi38]

Mike... I'm happy you agreed with me.
We are not alone, maybe it's just the beginning of a revolution... hum...
An answer from NI would be great too. Oh wait, I forgot nobody else was listening !

[mikeporter]

In a couple weeks on my blog I'm going to be doing a bit about object-oriented. Monday's post is already in the can and I have the outline in place for the week after. But after that I"m going to do a couple on OO techniques, but small entry-level stuff to help people get started.

Mike...

[smi38]

great ! please let me (us) know about that, on this post for example

[Jacobson-ni]

---

@mikeporter wrote:

PS: About that "stinks on ice" comment, that's just between us right? Nobody else was listening right?

---

Well I read the comment as "sinks on ice" so I suppose you could count that as not really listening (not sure if I have ever heard that saying before but I think I like my version better).

I've looked at the AF example a couple of times and have tried going through the hands on but still have a very hard time making sense of what is actually happening.  As someone still trying to learn AF, what are some tips you have when trying to learn this framework and what do you think are some common misunderstandings?  I'll also have to make sure to check your blog in the future mike, OOP is something I struggle with quite a bit.

[mikeporter]

My advice concerning the AF is simple: Ignore it. It's not worth your time. Its not an accident that many of the post you see here bemoaning (bizzare) problems they are having with OOP start:

"I'm using the Actor Framework..."

Mike...

[Romain_Duval]

Hi all,

In my case, I got interested in the AF when i saw some limitation about plugin consideration and maintanability using standard QMH based architecture.

Using a lot QMH based architecture and wondering about some of its limitation, the understanding was a bit easier for me though I am far from being an AF expert. Though this is really interesting, I don't think knowing the low-level of the framework is mandatory to use it in a good way. 

I wouldn't say such things as "never use AF" or "Always use AF" but at least try it and see if it can fit the requirements for some of your projects. This is actually the same kind of advice I give to beginners in LVOOP.

Regards,

[smi38]

Hi,

Let me add some informations :

I don't know how is the "story" elsewhere, but here is the "story" in France :

Once uppon a time, in a country with a lot of frogs and wine, little companies, called NI partners were born.

From this time to "now", these companies used a simple but "powerfull" high level template.

This template was a "secret", each company tended to think the other one didn't know about it.

It's name was.... "la machine d'état" (in french), akka "the state machine".

But this name is wrong, the real name is the "Queue Driven Message Handler" or QDMH or QMH or QSM.

Trust me, a lot (the most) of NI partners in France still use it.

And trust me, a lot (the most) of NI partners in France use it regardless of the problem to use.

"Today", object based structures tend to be THE good stuff to use, and the QDMH tends to dicrease in popularity. There are pro and cons.

It has been discussed a lot, especially by Daklu (https://lavag.org/topic/13064-object-based-state-machine-pattern/).

I understand all you arguments and I confess : I use objects in my LV developments but I'm not a specialist (but I'd like to ^^).

I accept this evolution and I want to use more and more object in the future.

In the Core3, NI wrote about objects, so I'm tempted to show some stuff about objects.

In the NI training, including the Core3, NI use the magical rules : "readable, maintenable and scalable".

I admit QDMH is not as powerfull as it seems, so it is not "really" scalable.

In the other hand, I think the AF doesn't suit the "readable" rule... it is "overly complex and essentially unreadable" like Mike Porter said.

Finally, I just expected a template based on objects, but with 2 big characteristics :

- readable (simple) like the QMH

- usable """""""everytime"""""" like the QMH (please, don't bite me)

The command pattern seems to fit with that :

https://ekerry.wordpress.com/2012/01/16/oriented-design-patterns-for-labview-tha t-can-make-your-lif...

Regards,

SebastienM

[Romain_Duval]

It is not the topic of the forum but contrary to you I think this is important to make the distinction between a LabVIEW state machine and a LabVIEW Queue Driven State Machine / QMH/ QDMH. As the first one does not imply using a queue to share Next-State(s)-to-execute info between cycle. And most important the QMH/QDMH/QDSM allows for stacking next-state-to-execute info from external process (I mean other while loop or async process) which is not possible with a "local" shift register.

So finally QDMH/QMH/QSM is a design pattern based on another design pattern called a state-machine that allow more flexibility and inter-process communication leveraging the use of queues.

Regards,