LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Follow-up questions from "G Interfaces in LV 2020" webcast (May 1, 2020)

This thread is for asking additional questions of Stephen Loftus-Mercer (Aristos Queue) and Allen C. Smith (justACS) after the "G Interfaces in LabVIEW 2020" webcast. We will leave this thread open for a couple of weeks for people who watch the recorded presentation.

 

I have also included my slides from the presentation. The VIs I was showing all ship with LabVIEW 2020 in "examples\Object-Oriented Programming\Basic Interfaces\"

 

The video for this presentation can be found here: https://youtu.be/u1rQ36Faxmc

Message 1 of 50
(2,663 Views)

In terms of subclassing Enqueuers, is it correct to think that I can (by manual intervention) have a single interface per Actor if I want, but that the problem (multiplicative vs additive) refers to having an Actor inherit from multiple interfaces?

 

Edit: It seems like if this were the case, I could create an interface which inherited from the union of interfaces the Actor wanted to inherit from, then I could inherit from that instead, giving an arbitrary number of interfaces. However, when I go to Build Array or similar, I now need the intersection of their sets of interfaces (which I don't see a way to do in 2020). But that still seems like an additive (well, subtraction...) problem, so I guess I still didn't work out what you meant. If multiple unions of interfaces contained an intersection with more than one interface (excluding Message Enqueuer.lvclass), then it could still (again, not in 2020, but perhaps conceptually?) continue with the union of the intersection of the unions of the interfaces from the Actors. I don't *think* that doing this repeatedly causes recursion... just the same operation over and over. Maybe that's not true.

 

Can you give me a quick pointer as to which operation causes multiplicative problems?

 

If I wanted to do this, would Launch Actor Core.vi be the place to do it (some sort of optional Enqueuer-type input, defaulting to Message Enqueuer.lvclass)?


GCentral
0 Kudos
Message 2 of 50
(2,572 Views)
Is there a link to watch the recorded webcast?
0 Kudos
Message 3 of 50
(2,522 Views)

The same link that could be used live: 

https://t.co/XUZKvffDUM?amp=1


GCentral
0 Kudos
Message 4 of 50
(2,516 Views)

For more complete details: https://lavag.org/topic/21539-webcast-for-g-interfaces-may-1-1030am-cdt/ 


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 50
(2,507 Views)

@cbutcher wrote:

Can you give me a quick pointer as to which operation causes multiplicative problems?


Our goal is an enqueuer that will accept all the messages that can go to a given receiver and not accept anything else. So let's say the receiver is of type Child. It has a Parent and above that is Actor. 

 

An enqueuer for Child should accept any messages that can go to Child, Parent, or Actor. 

 

The framework has class Message.lvclass. Anything that can go to any actor inherits from that class, so that's seems easy: we make the Send terminal of type Message...

 

And right there, we have a problem. We don't want to accept ALL messages. We want to accept only those Messages that can go to Child, Parent, or Actor -- but not the other descendants of Actor or Parent. So we want to accept Last Ack, Stop, and anything else that targets Actor. 

 

Ok, so let's introduce an interface "ReallyForActor". This interface is going to be applied ONLY to Last Ack and Stop classes and anything else that really does target Actor. This means that the input terminal of our Enqueuer is going to be at least type "ReallyForActor" so it can accept those messages. 

 

Now we also want the terminal to accept any message that is really for Parent. So we create the ReallyForParent interface and apply it to the messages of Parent. Should ReallyForParent have any relationship to ReallyForActor?

 

Option A: Let's say that ReallyForParent should inherit from ReallyForActor. This does not help us. If we make the input terminal of the Enqueuer be ReallyForParent, now Stop and Last Ack cannot be sent because they are not ReallyForParent. And if we make the terminal be ReallyForActor, it will accept all the messages for Parent, but it will also accept all the other messages for all the other actors that also inherit from ReallyForActor! ReallyForActor needs to be sealed -- no more descendants. If it can be derived from, then it doesn't fulfill its role in limiting what messages can be passed. 

 

Option B: Let's say that ReallyForActor should inherit from ReallyForParent. Ah, this is more interesting. Now we can make our Enqueuer accept ReallyForParent. All the Actor messages and all the Parent messages can fit through this pipe! But that means that every time anyone creates a new actor class, the framework's own ReallyForActor interface will be modified! That's not a viable solution -- ReallyForActor cannot be walking around with every interface for all actor messages ever created.

 

So there's no relationship possible between our two message interfaces, ReallyForParent and ReallyForActor. They don't composite on each other. And yet we need an Enqueuer terminal that can accept *both*. We end up needing the union of these two, and then we get a wire type that is also the union of these two. When Child's own ReallyForChild interface comes into play, it needs to be mixed into the set. It is a bit of a stretch of the metaphor (and math), but not much, to say we could not just add up all the interfaces, but instead, we had to multiply out the interfaces and create a new type for Enqueuer's terminal and for the wire from that terminal. 

 

In theory this is totally safe to build because all the operations for manipulating objects while they are in this superposition wire are dynamic dispatch -- primarily flatten/unflatten, copy, and compare. When they come out of superposition, it is either a To More Specific node or just a call to a dynamic dispatch method (and they have their own specific strong type on their dispatched block diagrams). 

 

That union of types is a compound thing that is outside the domain of both class and interface. But without something like that, we cannot write a communications pipe that is type safe and can discriminate correctly at compile time what to accept and what to reject. 

Message 6 of 50
(2,484 Views)

Is a house key a tool?

Jarrod S.
National Instruments
0 Kudos
Message 7 of 50
(2,437 Views)

I have a large AF project that makes extensive use of PPLs (some of which are actors). Did the Actor Framework.lvlib structure or API change in any significant way that would necessitate relinking code and/or creating a new AF PPL in 2020 or is it basically the same as in 2019?

 

(I'm thinking mainly about how interfaces can contain actor messages and wondering if the Message.lvclass was removed/decoupled from Actor Framework.lvlib.)

CLA CLED
0 Kudos
Message 8 of 50
(2,417 Views)

Quick question on Option A:

If ReallyForParent inherits from ReallyForActor, does that not then imply that ReallyForParent should extend ReallyForActor and therefore accept Stop and LastAck?

Maybe I am misunderstanding how Interface Inheritance works here.

-John
------------------------
Certified LabVIEW Architect
0 Kudos
Message 9 of 50
(2,414 Views)

@Jarrod_S. wrote:

Is a house key a tool?


No, in the shipping example, House Key inherits from LabVIEW Object. I don't think we need to make the edit to the project that Stephen made during the presentation.

DNatt, NI
Message 10 of 50
(2,388 Views)