Merge Class Data

[DTaylor]

2 hours ago, Aristos Queue said:

Most languages (Haskell, Racket, Erlang, Lisp) that are successful in taking full advantage of multicore parallel programming do not allow references.

Haskell has IORef, which along with modifyIORef/modifyIORef'/atomicModifyIORef etc functions a lot like a DVR + IPE structure. Haskell and Clojure (I don't know about other Lisps) both have STM reference implementations, which just require thread-safe transactions to update the values they reference. Rust has a strong emphasis on memory safety and "fearless concurrency", and it has several reference primitives. I think there are a lot of valid use cases for references, and I like that DVRs exist in LabVIEW.

Depending on what OP is trying to do, I do think your solution is best.

2 hours ago, Aristos Queue said:

Computer science has had a better way to program since the 1940s, but Van Neumann saddled us with the IBM hardware architecture, and direct addressing of assembly and then C and its successors won performance at a time when such things were critical. Hardware has moved beyond those limitations. It's time for software to grow up.

Functional programming? Does this mean that you're going to get this idea resurrected?: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-Enum-Class-Primitive-quot-The-Defined-Enum-quot-with/idi-p/1904525

[smithd]

12 hours ago, DTaylor said:

Rust has a strong emphasis on memory safety and "fearless concurrency", and it has several reference primitives. 

Rust seems to focus on moving references around and passing ownership between chunks of code, which isn't far off from dataflow. The thing rust can do that labview can't (through dataflow) is retain a read-only reference to a mutable object elsewhere. I believe the recent changes to the IPE (http://zone.ni.com/reference/en-XX/help/371361P-01/glang/inplace_datareference/ concurrent read only access) allow this though, but you're still stuck with the horror of the IPE and you have to do extra work to make it read only. 

Edited July 22, 2017 by smithd

[Aristos Queue]

ShaunR: You can still program procedurally in LabVIEW. That's what DVRs+methods allows.

[ShaunR]

5 hours ago, Aristos Queue said:

ShaunR: You can still program procedurally in LabVIEW. That's what DVRs+methods allows.

I can also undo screws with a knife but I would prefer to use a screwdriver

[Rolf Kalbermatter]

On 6/20/2017 at 0:15 PM, CraigC said:

Hello,

I still feel a little uncomfortable about putting things into a hierarchy and although smithd is technically correct... measurements can all have limits and each test all has execution behaviour.  Having said this composition is fine and there is no real need for hierarchy here.

I"m not quite sure if you mean to advocate a class hierarchy for an "has" relation. Part of the sentence sounds like it, then again the other part seems to indicate you mean not.

One of the first principles in OOP anyone needs to understand is that two objects can either have an "is" relationship or a "has" relationship. For an "is" relationship inheritance is usually the right implementation, for "has" you should make the "owned" object a value/property of the owner, which could be by composition.

[CraigC]

Hi Rolf,

On 25/07/2017 at 8:59 AM, rolfk said:

I"m not quite sure if you mean to advocate a class hierarchy for an "has" relation. Part of the sentence sounds like it, then again the other part seems to indicate you mean not.

One of the first principles in OOP anyone needs to understand is that two objects can either have an "is" relationship or a "has" relationship. For an "is" relationship inheritance is usually the right implementation, for "has" you should make the "owned" object a value/property of the owner, which could be by composition.

Thats a handy way to think about it thanks for the tip.