Has anyone ever felt the desire to restrict a field to a single method?

[Aristos Queue]

Taking my previous statement about "static". In other languages I could put a static variable in one of the methods to count the number of times that method/function had been called. This would translate (I think) into a single VI method with local (to that VI) storage outside the purview of the cluster (i.e. only accessable inside the function but could be exposed via a terminal of that VI - the return value in other languages). Is this a similar scenario to what you are describing here? Or am I really out there in my understanding?

This would be "a field that you could declare to count how many times that particular data structure had passed through that particular method". So similar to static but with an added dimension of allegiance (I use that word in this context because I'm not sure how else to describe it).

 

I suppose, describing it like that, it would be akin to having a database of "people". Then you have a "Look up records" function. Every time one person's record is looked up, the "# of times accessed" field would be incremented. Then you would have a record of how many times that person's records had been pulled up. But the only function capable of doing anything with that number would be the "Look up records" function... no other function even knows the value exists. So you *could* use it as a security check, "This record has been accessed too many times." And, like you said, you could make it an output from the function if you wished (like copying out the value of an uninitialized shift register). But at that point you're exposing the value out of the function, so isolating it to the function doesn't seem to make much sense. At least to me, at least right now at 4:20am. I am not seeing any useful data encapsulation that it buys you that private data doesn't already buy.  If there is any value in it, it is in refactoring ... were I to delete the "Look up records" method, this field of the object would go away without me having to change the private data control. Similarly, if I added the "Look up records" method, I could add it to the object without editing the private data control. Akin to Java aspects? Maybe... worth researching. Although I've never really been too fond of aspects... They behave a bit too much like Befunge's "Come From" statement... any of you who have ever heard of the "goto" statement, well, Befunge, as a joke, added the "come from", so your program just jumps randomly when it hits a particular memory address, to some other part of the program. Totally impossible to debug. Aspects have that sort of "glommed on" feel. This might too, but since it gloms on it a more obvious way, it might have utility there. I'll put it on the back of my breadth-first-search queue.

[lordexod]

This can be done now in one VI.

 

[Aristos Queue]

This can be done now in one VI.

Not meaningfully. For one thing, there's no syntatical meaning to that for the compiler to latch onto. For another, Timed Loops aren't on all platforms. And last, the EIO doesn't have any relation to the borders of the timed loop.

[lordexod]

For another, Timed Loops aren't on all platforms. - Which platforms don't have?

And last, the EIO doesn't have any relation to the borders of the timed loop. - But they can have. (After the makeover.)

[Aristos Queue]

For another, Timed Loops aren't on all platforms. - Which platforms don't have?

Mac and Linux.

[lordexod]

What is this "SDFX_DockYard.xnode" on Mac platform.

[Daklu]

So I'm asking... suppose you could write a method of a class and in that method declare "this is data that is local to this VI but it becomes part of the state data of the object overall such that if the wire forks, this data would fork too."

 

Nope, haven't ever run into a situation where I wanted that functionality.  Can't think of one either.  I strongly suspect that any situation where I would want that kind of functionality would be better solved by refactoring that method into it's own class.

 

 

That lead me in the direction of "What if data is not static on a wire? Suppose it were actually doing something as it traveled down the wire?" In other words, package up a still running state machine and send it, as it is running, down a wire to be transformed.

 

Passing around code components *is* something I have wished for before.  I don't remember the context that led me to want it, but I'm pretty sure I was wanting to send an entire executing component over a queue.  We can send a running state machine down a wire right now to some extent using vi references, but it requires more framework and coordination than I've ever felt like writing. 

 

Still, I think you would have to be very careful how this is presented conceptually.  Changing the "data on a wire is immutable" axiom opens the door for all sorts of confusion.  Adding more language elements (vi, while loop, .lvlib, etc.) to the list of first class objects Labview supports is somewhat less confusing.