Where to put to more specific class?

[SteveChandler]

I put a post on the LapDogAPI group six days ago but have not got any replies.

What I have started doing is to wire the parent message class to my get message VIs and do the cast in there. For me it seems too tedious to have to do the casting everytime that I get a message. In fact this is the very reason that I posted the "Wire Class to Case Selector" idea.

Instead of this

I can do this. The to more specific class is inside the SubVI.

Is there any reason not to do it like that?

[jgcode]

[Cross-posted to NI]

[SteveChandler]

[Cross-posted to NI]

Yes as I mentioned I posted it there a week ago. The NI sites don't seem to get as much discussion as Lava does so I thought I would post it here. I hope that is ok. I am starting to think it is a dumb question.

[jgcode]

Yes as I mentioned I posted it there a week ago. The NI sites don't seem to get as much discussion as Lava does so I thought I would post it here. I hope that is ok. I am starting to think it is a dumb question.

Hi Steve

No probs cross posting, it's just considered polite on forums to state that and to include a link in all cross threads so that anyone replying in one thread might not waste time repeating something on another thread; or for readers to find additional information etc...

Cheers

-JG

[SteveChandler]

Thanks. I mentioned that I posted it on the LapDogAPI group but forgot to put the link. Fixed.

I am in the process of modifying all the native types in LDM to take the parent class as the input and I am putting the to more specific class in those. As one of the LDM developers do you see any inherent problems with that? It does what I need it to but I was just curious why it is the way it is.

[Ryan Podsim]

I'm afraid i don't quite understand what your trying to do. I haven't looked at the LabDog API, but I'm wondering why you can't use the Dynamic dispatch functionality of the LVOOP classes? it might help if you had made you examples use the same case.

If your updating UI elements (ie: controls) you could use Control refs inside the message class function instead of having to cast to a specific class.

[SteveChandler]

Messages return different types so they can not be overridden. My question really is about why the API was designed the way it was. I know there probably is a reason that I cannot think of. Just a curiosity is all.

[Ryan Podsim]

That was my question... Why do they need to return different types. (though, it would be nice to be able to force the dynamic dispatch to a specific child. ( hmmm need to look at the Idea Exchange).. (on a side note why isn't the idea exchange www.ni.com/idea?))) So many possibilities.. which one to choose... i can't fault the current implementation, but I would like the ability to Auto Cast (ie. wire a specific child to a parent wire) so that I could place a child function on a BD and not break my code (I bet there are reasons for this, but it would be nice if say the call function output a failed cast.... ( hmmm like the to specific class) but then that would require functions to have an error out.... dang it.. decisions... hmmm maybe some sort of Exception implementation? It would be nice if we have the option to include the error cluster in VIs and if an Exception implementation occurred then it would be places on the error wire? Dang It.... I don't really want that, but it's a possibility especially, with "out of memory errors"...

Hmmm... on a side note; why can't I capture out of memory errors? (Idea link to come soon)

[drjdpowell]

What I have started doing is to wire the parent message class to my get message VIs and do the cast in there. For me it seems too tedious to have to do the casting everytime that I get a message.

I made the same design choice in my own version of object messaging. Though I'm also not sure if there isn't a problem with this way of doing things. One possible advantage of having a VI take the parent class is that you have the option of handling more than one message type. For example, the VI to get a String might work for both a String message type and a Variant message type, where the variant contains a string.

-- James

[Daklu]

Sorry for the late reply Steve. I kept getting an error when I tried to reply to the LapDogApi thread, so I tried to use the email reply feature. Four days later the email bounced back to me.

Here's my original response:

"No, you're not overlooking anything. There are a couple reasons I do it that way, none of which are enough of a concern to prevent you from downcasting internally.

1. Clarity. Since most of the people who look at the code will not be familiar with what I'm doing, I try to make it as easy for them to read as possible. I think explicitly showing the downcast helps make the connection between OO messaging and string/variant messages.

2. Laziness. When there are multiple accessors to retrieve various bits of data from the message, I'd have to put the downcast in every accessor in case the next developer changed the order in which the accessors are called.

3. Convention. I always make the top left and top right conpane terminals use the class constant of the class the method is a member of. I just find it easier to read that way. I had to look at your second diagram for a bit before I realized your input terminal uses the Message class, not the GUI class. (Easily worked around by moving the Message class input to a different terminal if you were so inclined.)

Seems to me the difference is 95% stylistic, with *maybe* 5% being readability. As long as you're consistent the readability issue goes away. I wouldn't worry about it too much.

(Oh, and I like using messages bundled inside a user event to send data to the event loop too. It's way cleaner than creating all those user events manually.)

[Daklu]

I am in the process of modifying all the native types in LDM to take the parent class as the input and I am putting the to more specific class in those...

I don't recommend modifying the LapDog classes directly--it can easily lead to maintenance issues down the road. Every time I release an update you'll have to go back and modify them all again. (Or choose not to update to later releases.) It also can create problems for future developers. ("I installed the LapDog Messaging package. Why isn't this working?")

Alternative 1 - Easy cheezy:

One route would be to create a separate vi that wraps up the downcast and getter for each message type. Tie them up in a project library and use that instead of the LapDog palette. When more message classes are created all you have to do is add new vis to the library. You could even package it up and release it as a LapDog Messaging add-on if you're feeling ambitious. When a LapDog Messaging update is released, upgrading to the new version would be pretty painless.

Alternative 2 - More work:

Another solution is to subclass each of the message types included with the library and add a 'Get StringFromMessageObject' method to each subclass that does the downcasting and and returns the data.

Personally I think the first option is a little cleaner. It clearly differentiates between the message framework and your convenience vis.

[SteveChandler]

Sorry for the late reply Steve. I kept getting an error when I tried to reply to the LapDogApi thread, so I tried to use the email reply feature. Four days later the email bounced back to me.

Here's my original response:

No problems. The NI sites have been flakey lately. Since this seems particular to LapDog I wanted to post it there to hopefully spark more discussion of it. It sure is a low volume page. I then thought it might be better to put it here to increase visibility.

"No, you're not overlooking anything. There are a couple reasons I do it that way, none of which are enough of a concern to prevent you from downcasting internally.

Seems to me the difference is 95% stylistic, with *maybe* 5% being readability. As long as you're consistent the readability issue goes away. I wouldn't worry about it too much.

(Oh, and I like using messages bundled inside a user event to send data to the event loop too. It's way cleaner than creating all those user events manually.)

That totals 100% so it answers my question. I thought that later I might wish I had done the cast externally if I wanted to do something that does not occur to me right now.

I don't recommend modifying the LapDog classes directly--it can easily lead to maintenance issues down the road. Every time I release an update you'll have to go back and modify them all again. (Or choose not to update to later releases.) It also can create problems for future developers. ("I installed the LapDog Messaging package. Why isn't this working?")

I meant that I modified them and saved them in my own library. They look like this:

Also my create messages actually do more than just create the message. They create the messages and send them. I guess this is not really a modification but usage. I use the native types "in a modified way".

Does your next version expand the list of native types? Also would it be possible to use polymorphic VIs? This is something I might be willing to help you on. I think working with you on the project would be good excersize and this part is simple enough that I could probably handle it.

[Daklu]

It sure is a low volume page.

Yeah, especially when users can't post to it.

Also my create messages actually do more than just create the message. They create the messages and send them.

This is where you could potentially run into trouble. What happens if you want to create a message without sending it right away? One key to a good reuse api is to not make each unit (component, class, method, etc.) do too much. If the unit's description includes the word "and" it's a pretty good indicator for me that I need to rethink the design a bit.

Sometimes I will create those kinds of convenience methods. In the snip below each of those SendRefresh... methods obtains data from the class and sends a message to the UI loop. However, these methods are part of the application code, not the reuse code. I wrote these specifically to improve readability. They are not intended to be reusable beyond this application.

Does your next version expand the list of native types?

Dunno... haven't written it yet. I've considered expanding the list of native types supported. I think I have messages for arrays for all the current native types hanging around somewhere. I haven't had to use it very often and I've never received a request to add more stuff... so I didn't release it. I've thought about releasing a Command message add-on pack. It's trivial to implement but it might help people understand what they can do with the library. I've also thought about creating a more feature-rich Error message, but first I'd want to use it myself in a couple applications. (After I actually build it of course.)

Also would it be possible to use polymorphic VIs?

Possible? Yep. The EnqueueMessage method is polymorphic. Fair warning though... I'm not a super big fan of polymorphism in a reuse library, especially if the set of polymorphic methods is open-ended. You'll have to convince me that what you have in mind is a good idea.

This is something I might be willing to help you on.

Let's talk. I've been chatting with Minh about a follow up discussion to my user group presentation last week. My guess is it will be late this week or early next week.

[SteveChandler]

Let's talk. I've been chatting with Minh about a follow up discussion to my user group presentation last week. My guess is it will be late this week or early next week.

A followup would be good. The material is still somewhat fresh in peoples minds and I am sure there are some points that you didn't get to make since it was such a lively group ( that and because the pizza was 20 minutes late).