Argument cluster to typedef?

[1984]

Hi,

looking for a best practice (if it exists): the argument of my request&reply - besides the error cluster and the wait notifier - is cluster(A). Within (A) there are two other clusters (B) and (C).

(B) and (C) are typedefs. The question is: should I make (A) a typedef? 

To expand my question: in general should the arguments of a request be a typedefs? Something suggests me that its probably a good idea because then I could be sure that my input always matches the input required by the request itself. On the other hand if this would be such a good idea then it probably would have been scripted like this.

thx.

ps.: two years after I had to drop labview I'm back on a project I need to use DQMH. Pretty excited to see whats news!

[Ludwig72]

Hi,

as best practice from my side: don't use typedefs inside arguments. If you need typedefs it is better to cast your argument cluster inside the request MHL and at the callers side also.

The goal is to decouple the modules so that they can run independently and minimize dependencies and cross-references between them. This provides several advantages, including easier debugging, faster compilation, and improved reusability of individual DQMH modules.

[1984]

Lets you dont make them typedef and you started to use the request gazillion places. Then you realize that the the cluster you had in the arguments needs to be updated with a new field. In this case - I assume - you need to find every places you called the request and modify the inputs. This looks quite a job to do.

Do I miss something?

[joerg.hampel]

Do I understand correctly that you're talking about a situation like this one:

Yes, definitely: A, B and C would be type definitions for me. Argument or no argument - a cluster should be typedef'ed.

Related question: Who will own those typedefs? Are they members of that module?

[1984]

Yes, this is the argument I tried to explain.

I think the typedefs should be owned by the DQMH module itself because ultimately the request is the end user of the data.

[drjdpowell]

A suggestion for consideration:

Have separate inputs on your request SubVI for B and C.  Don't expose cluster A outside the Module at all.  If you add a third thing later on, this is another input, which can be set required if you want to force users to include it.  

[Taggart]

Be very careful with typedef ownership. It can easily create unwanted dependencies. I tend to try to use simple types where possible when data crosses boundaries and only use typedefs inside modules/components. That limits unwanted dependencies. Definitely if you need to share across boundaries, the depended upon component should own the type def.

[Darren]

This may seem like anathema, but on the past couple of projects I've worked on, I've been creating a top-level non-namespaced folder in the project that contains utility VIs and typedefs that are used across different libraries/classes in the project. That way I don't have to worry about ownership of those shared components. It's been working well. I only need to worry about tightening that up if I end up reusing a class/library in a different project, but that doesn't happen very often... most of the libraries/classes I write are project-specific.

[Taggart]

---

@Darren wrote:

This may seem like anathema, but on the past couple of projects I've worked on, I've been creating a top-level non-namespaced folder in the project that contains utility VIs and typedefs that are used across different libraries/classes in the project. That way I don't have to worry about ownership of those shared components. It's been working well. I only need to worry about tightening that up if I end up reusing a class/library in a different project, but that doesn't happen very often... most of the libraries/classes I write are project-specific.

---

very similar to what I do when I have a typedef that's needed by multiple components.

[Ludwig72]

This topic is becoming really interesting. Can we pin this somewhere as a best practice?