Clever Move or Bad Move?

[BenFarmer]

Hi,

I am just getting started with DQMH and I am wondering if this technique is a good move or if there are reasons to avoid it.

Lets say I have two modules, Module A and Module B. I create a Request event in Module B called "Call Module B Message Case" with the same arguments for enqueuing a message, a string for the message and a variant for the data. Module A can then use this single Public Request to execute any case in the MHL of Module B and change its state.

Thoughts?

[Taggart]

My question is: Why?

What are you trying to achieve?  What is your use case?

[Taggart]

also try not to be a clever programmer, because the next guy who comes along is probably not as clever and won't have a clue what you were trying to do (and that next person could be you, several years from now.)

[BenFarmer]

In this case, Module A is a system controller module and Module B is a display module. The controller module contains the main user interface meaning that the controls/buttons reside there, while the display module is mostly reserved for indicators / graphs.

My thinking for creating the "Call Module B Message Case" request is: if I have a lot of interactions/requests that go down into the display module or need to extend it's functionality in the future, I have a generic request already created that I can use to facilitate. I would just need to create the new message case in the display module and could then call it from the controller with the generic request- rather than create a new unique DQMH request event.

Does that clarify the use case? You are right, clear programming is better than clever programming. To me it seemed harmless to do it this way but wasn't sure if there was a can of worms that I was opening somewhere.

[joerg.hampel]

If I understand right what you're proposing, I don't think that's a good idea. You'd circumvent the strongly typed API - my favorite feature of DQMH.

Would you create typedefs for the manually created messages? If not, you end up with "external" functions that are not documented at all in the API. If yes, what's the benefit of not just creating a request?

Would you make Module A use the typedefs of Module B's messages? If yes, then you don't really gain a lot (and you still have static linking). If no, then you still need to know the data type, so Module A needs to know about Module B's internals (they're are still linked, even if not statically).

Maybe I got your idea all wrong, so please let me know your thoughts. 

[BenFarmer]

Ok, thank you for the clarity!

I figure that since I was asking the question in the first place, deep down I must have known that there was something smelly about this method. You've cleared it up nicely. The self documenting of the API with defined requests is preferred. A future developer could quickly understand the scope of the module's event structure. Thanks.

[drjdpowell]

It's important to understand a framework's intended use before trying to improve it.  Although using weak instead of strong typing is a legitimate choice, that is not what DQMH is built for.  One could easily lose the advantages of strong typing without gaining the full benefits of weak typing.

[FabiolaDelaCueva]

Hi Ben,

Expanding on what everyone has already said:

The Queue in the DQMH module is private, the idea is for the Request VIs and registering for the Broadcast events to be the public API. The API Tester that pops up every time you add a new event is there to test and provide a map for future developers on how to use the public API for the DQMH module. 

Another advantage is that you know that if something makes it into the MHL, it was generated internally, if something arrives via the EHL then it comes from the outside. 

The generic message would open a back door into the module and remove that troubleshooting advantage.

Thanks for your trust in DQMH,

Fab