Best Practice Question - References as... Type Defs?

[DailyDose]

With many projects, you have several queues running around with different data types.  Even different DVRs.  And some clusters, objects, etc containing those Queue or DVR refs.  And what I have found that many times, I suddenly need to update a cluster that is the data type of some queue whose ref is in another cluster somewhere else.  And many times, I don't remember which cluster contains the queue ref.  So with this in mind... does anyone make type defs of Queue refs and DVRs and any other ref that makes sense and just update those specific type defs so that anyone containing them gets updated?

[Jay14159265]

---

@DailyDose wrote:

With many projects, you have several queues running around with different data types.  Even different DVRs.  And some clusters, objects, etc containing those Queue or DVR refs.  And what I have found that many times, I suddenly need to update a cluster that is the data type of some queue whose ref is in another cluster somewhere else.  And many times, I don't remember which cluster contains the queue ref.  So with this in mind... does anyone make type defs of Queue refs and DVRs and any other ref that makes sense and just update those specific type defs so that anyone containing them gets updated?

---

What I used to do was create a data transport layer such that queues cold only transfer a "queue message" object that was of the data transport layer class. For each cluster or object that needed to be transported through a queue, it got its own subclass data transport layer object. This way the data type was linked to the message. The parent of the data transport layer object was an Inter Program Communication layer object that had a ref to all the valid Queues so you could register for a queue and then request the latest state or variable from some other context. This way you can update a local cluster with data from some code that is executing outside of the current context. After figuring out the Actor framework I stopped using all that though, it makes everything soooooo easy. 

[DailyDose]

I might should look into Actor Framework.  I've been avoiding it for some reason.

[JÞB]

While I don't typedef the references I always typedef the data or, use a class.ctl

My convention is to use [Q|N|C|D]Name_Data<Name_cmd.ctl,data> like "QLog_Data.ctl" as cluster of enum QLog_cmd, Data where Data may be any element(s) of the cluster or I may just use String,  Variant as an actor class does.

N for Notifiers

C for Channels

D FOR DVR.....

---

@DailyDose wrote:

I might should look into Actor Framework.  I've been avoiding it for some reason.

---

Chose "Should" even if you don't use it your code will be improved by the concepts.

[DailyDose]

So my typical fix for this has always been to make my data a variant and then change back to appropriate data type.  But that's now how this project I got hired to do was doing it.  Should I just flex and be like... yo, this is wrong?  Use Variants because it's annoying and easy to make a mistake otherwise?

[Mark_Yedinak]

---

@DailyDose wrote:

So my typical fix for this has always been to make my data a variant and then change back to appropriate data type.  But that's now how this project I got hired to do was doing it.  Should I just flex and be like... yo, this is wrong?  Use Variants because it's annoying and easy to make a mistake otherwise?

---

I guess it depends on how you were using the variants. I will explicitly type the type for queues/notifiers/events to avoid issues when converting back to the known type. I do use strings for generic messaging classes at the lower level libraries. At the application layer everything is explicitly defined. So, are you libraries general purpose or application specific? If general, a generic data type is required. If this is at the application layer I would explicitly typecast the data types. Let the compiler find the errors and let your code break when you actually do break it. It also simplifies the code since you don't have to convert the data back and check for errors if you try to convert the data to an invalid type.

[JÞB]

---

@Mark_Yedinak wrote:

---

@DailyDose wrote:

So my typical fix for this has always been to make my data a variant and then change back to appropriate data type.  But that's now how this project I got hired to do was doing it.  Should I just flex and be like... yo, this is wrong?  Use Variants because it's annoying and easy to make a mistake otherwise?

---

I guess it depends on how you were using the variants. I will explicitly type the type for queues/notifiers/events to avoid issues when converting back to the known type. I do use strings for generic messaging classes at the lower level libraries. At the application layer everything is explicitly defined. So, are you libraries general purpose or application specific? If general, a generic data type is required. If this is at the application layer I would explicitly typecast the data types. Let the compiler find the errors and let your code break when you actually do break it. It also simplifies the code since you don't have to convert the data back and check for errors if you try to convert the data to an invalid type.

---

If it's generic reuse....use general types. < String, Variant >  the documentation of the general API  will contain the example, notes and any caveats ( as the Actor Framework  on DQMH do).  OTOH, if it is application specific or a project limited lvlib, BREAK THE CODE as Mark said, when the other developers make a mistake using the library.  They should never need to test a string driven default (typing error) case for a command that AF wouldn't let them code anyway.