Crazy LVOOP idea: Streams

[eaolson]

This thread got me thinking: would it be possible to implement something like the Java stream classes in LabVIEW? (And would there be any point in doing so?) The two sorts of things that come to mind are file streams and piped streams for inter-thread communication. The former could be a wrapper around the file VIs, and the latter would be a wrapper around a queue.

On the other hand, with LV's strong typing, you'd probably have to have a different implementation for each data type or handle everything as variants with Variant to Data nodes all over.

I was thinking something like:

Stream

|

+-- FileInputStream (methods for reading data)

|

+-- FileOutputStream (methods for writing data)

|

+-- DoubleStream (similar to Java's PipedStream, has both read and write methods)

|

+-- IntegerStream (same as DoubleStream, but for integers)

|

+-- etc.

Is this a stupid idea? I don't really have much spare time right now, so I can't work up an implementation, but will try to do so when I can.

[shoneill]

QUOTE (eaolson @ Apr 23 2008, 04:26 PM)

http://forums.lavag.org/Components-vs-Functions-newbie-warning-t10641.html' target="_blank">This thread got me thinking: would it be possible to implement something like the Java stream classes in LabVIEW? (And would there be any point in doing so?) The two sorts of things that come to mind are file streams and piped streams for inter-thread communication. The former could be a wrapper around the file VIs, and the latter would be a wrapper around a queue.

On the other hand, with LV's strong typing, you'd probably have to have a different implementation for each data type or handle everything as variants with Variant to Data nodes all over.

I was thinking something like:

Stream

|

+-- FileInputStream (methods for reading data)

|

+-- FileOutputStream (methods for writing data)

|

+-- DoubleStream (similar to Java's PipedStream, has both read and write methods)

|

+-- IntegerStream (same as DoubleStream, but for integers)

|

+-- etc.

Is this a stupid idea? I don't really have much spare time right now, so I can't work up an implementation, but will try to do so when I can.

Sounds like a decent enough Idea. You could develop Classes to stream whatever you like.

It's a bit of work though. Let me know when you're finished.....

Shane

[Aristos Queue]

QUOTE (eaolson @ Apr 23 2008, 10:26 AM)

On the other hand, with LV's strong typing, you'd probably have to have a different implementation for each data type or handle everything as variants with Variant to Data nodes all over.

If you have the right class hierarchy, the strong typing isn't a problem. Remember, in LV, a child class can travel on a parent class' wire. As long as all the information that you're streaming is classes, you wouldn't have difficulties. The hard part would be streaming the built-in data types (numeric, string, path, cluster, waveform, timestamp etc) -- those would either need to be wrapped in a class or handled by Variant, with all the overhead you were noting.

[shoneill]

QUOTE (Aristos Queue @ Apr 23 2008, 05:42 PM)

If you have the right class hierarchy, the strong typing isn't a problem. Remember, in LV, a child class can travel on a parent class' wire. As long as all the information that you're streaming is classes, you wouldn't have difficulties. The hard part would be streaming the built-in data types (numeric, string, path, cluster, waveform, timestamp etc) -- those would either need to be wrapped in a class or handled by Variant, with all the overhead you were noting.

Personally, I think the "Class for each data type" would definitely be the way to go. Variants are run-time bound meaning that errors are found too late. Finding errors at compile-time is very useful. :thumbup:

Having classes for U8, I8, SGL, or whatever would be great.

OK, this means duplicating code for a lot of things, but this brings me to a wish of my own for LVOOP. I want to be able to define interfaces, or abstract classes to help reduce this work. what's the problem? If I have a parent class with basic functionality and I want to "override" this in child classes, the parent is ALWAYS able to exist on its own in LVOOP. This is sometimes not wanted. The only other option is to duplicate the parent code in each and every child, basically negating the main benefit of the OOP approach......

OK. Rant finished.

Shane.

[eaolson]

QUOTE (Aristos Queue @ Apr 23 2008, 11:42 AM)

The hard part would be streaming the built-in data types (numeric, string, path, cluster, waveform, timestamp etc) -- those would either need to be wrapped in a class or handled by Variant, with all the overhead you were noting.

So it sounds like, if primitives inheritied from Object, that would eliminate this problem? (Hint, hint.) Or even wrapper classes around the primitives, with autoboxing/unboxing.

[Aristos Queue]

QUOTE (shoneill @ Apr 24 2008, 03:12 AM)

OK, this means duplicating code for a lot of things, but this brings me to a wish of my own for LVOOP. I want to be able to define interfaces, or abstract classes to help reduce this work. what's the problem? If I have a parent class with basic functionality and I want to "override" this in child classes, the parent is ALWAYS able to exist on its own in LVOOP. This is sometimes not wanted. The only other option is to duplicate the parent code in each and every child, basically negating the main benefit of the OOP approach......

It is logically impossible to have true abstract classes in LabVIEW. Every VI is independently runnable, and this provides a major advantage during development and testing. But in order to run parent methods, we must be able to instantiate parent data. And every parent control must have a default value. Again, this requires instantiating the parent data. The LVClasses team has been over and over this problem, banging our heads against it.

HAVING SAID THAT... it is perfectly legit to have a class that you treat as abstract, not ever actually using anywhere in your top-level VI. And there is a new feature in the next version of LV that will address one key aspect of abstract classes. But that's all I'm going to say about it for now.

QUOTE (eaolson @ Apr 24 2008, 10:11 AM)

So it sounds like, if primitives inheritied from Object, that would eliminate this problem? (Hint, hint.) Or even wrapper classes around the primitives, with autoboxing/unboxing.

It sounds like, if customers would just let me break binary compatibility and not load any existing VIs, this would be easy to implement. (Hint Hint) Unfortunately, it is a non-trivial challenge given 20 years of history, especially since classes aren't yet on all of the platforms that LV supports. It would be hard to tell FPGA "sorry, integers are classes now, so you can't use them". So all platform support for classes has to be a higher priority.

In the words of the Wicked Witch of the West from Oz: "These things must be done dellllllllicately, or you hurt the spell!"

[eaolson]

QUOTE (Aristos Queue @ Apr 24 2008, 10:39 AM)

HAVING SAID THAT... it is perfectly legit to have a class that you treat as abstract, not ever actually using anywhere in your top-level VI. And there is a new feature in the next version of LV that will address one key aspect of abstract classes. But that's all I'm going to say about it for now.

You could also have the methods of the abstract parent class throw an error if they run. That might help enforce non-instantiation of the parent.

QUOTE

It sounds like, if customers would just let me break binary compatibility and not load any existing VIs, this would be easy to implement. (Hint Hint) Unfortunately, it is a non-trivial challenge given 20 years of history, especially since classes aren't yet on all of the platforms that

LV

supports. It would be hard to tell FPGA "sorry, integers are classes now, so you can't use them". So all platform support for classes has to be a higher priority.

With 20+ years of history, I doubt any major paradigm shift is easy or quick to do. I was just thinking that if there were built-in numeric classes (e.g, Double) that could be automatically converted to their underlying primitive (e.g. double) at a coercion dot. I'm not entirely clear on what goes on at a coercion dot, but it seems that it has to be more than just a cast, since anything can be coerced to a Variant, and they carry attributes with them which didn't exist for the original coerced thing.

I'm not saying that universal support for classes isn't more important. It's just that, to quote Freddy Mercury, I want it all and I want it now. Please?