Objects Containing References - Discussion

[TomOrr0W]

During Q&A in one of his "An End to Brainless Programming" presentations, @Darren mentioned that classes wrapping any references should only contain references (From the 2020 GLA Summit - see https://youtu.be/pS1UBZzKl9k?t=1741).  This makes sense to me to some degree, as usually you don't want any associated data to be no longer synchronized with an internal reference after branching a wire.

It is still a new concept to me, though - if people are willing, I would like to hear more discussion/reasoning on the topic before I wholeheartedly adopt it as a personal rule.

Do you know of any other forum posts/whitepapers/recorded presentations on the topic - @Darren mentioned @Aristos Queue having talked about this before?  Do you agree with this as a general rule?  I assume that any classes containing an object that wraps references also should only contain references - is this correct?  Should this rule also apply to normal clusters containing references?  Can you think of any exceptions that might make a class with both value and reference data appropriate?

I did look through some NI APIs for exceptions, and found a couple in the Actor Framework's message classes: Actor Framework.lvlib:LastAck.lvclass wraps a by-val error cluster along with some objects containing only references (Actor.lvclass and Message Enqueuer.lvclass); Actor Framework.lvlib:Launch Nested Actor Msg.lvclass wraps a by-ref actor.lvclass with some by-val data.

[TomOrr0W]

Crossposted to the NI forums here: https://forums.ni.com/t5/LabVIEW/Objects-Containing-References-Discussion/m-p/4127970

[dhakkan]

Hello.

I haven't gone through the links provided in the opening post. However, it appears that Darren's recommendations pertain to the concept of (class or object) immutability - the general idea being that, once an object is created, its identity must be unique in your application domain. Note, however, this does not mean all class data members are constant - just the crucial attributes that 'define' the object. For example, a human being continuously evolves since inception. However, certain traits remain immutable, depending on the domain of reference: Biologically - DNA; Government - government issued ID#, etc.

In my case, I am happy saving certain class data members without references, because I know those don't get overwritten once the object is created. E.g. 'id' as string - gets assigned when object is instantiated. All others are saved via references. My general heartburn vis-a-vis references, is the worry of how to group the data members for referencing. One DVR for all class members, though easy to implement, has greater chance of causing deadlocks. Although those ought to be caught with adequate unit testing.

Of course, making all data members references ensures a consistency in implementation; as opposed to a mix of by-ref and by-val data members.

The Actor Framework is neat in this context - when a launch actor is invoked, the output is actually a reference to the actor's unique 'mailbox'. Therefore, regardless of the number of wiring branches one invokes on that output; all 'messages' go back to the launched actor. IMHO, there is no need to save class member data as references in such frameworks, as long as the actor's internal logic is implemented without risk of race conditions.

 

[drjdpowell]

It's the inconsistent state that is the problem, where the by-value bit is inconsistent after the by-ref bit is changed in parallel.   That doesn't always happen; sometimes either the value or the reference bit never changes.   But one needs to be aware of this issue.

[Darren]

2 hours ago, drjdpowell said:

It's the inconsistent state that is the problem, where the by-value bit is inconsistent after the by-ref bit is changed in parallel.   That doesn't always happen; sometimes either the value or the reference bit never changes.   But one needs to be aware of this issue.

Dr. Powell pretty much gave my answer (stated more eloquently  ). It's something to look out for when branching wires... by-value data is now a copy, while by-reference still refers to the same thing. Be aware of that when you start mixing by-value and by-reference inside class member data.