Are globals really THAT evil?

[tst]

You should note that the issue has never been how to implement such things. There are numerous options. The point was that globals have some significant ease-of-use features working in their favor.

[Broken_Arrow]

---

F. Schubert wrote:

[...]

But I must confess, that I really do use those evil globals to pass data around.

[...] 

---

That's OK Felix, you have over 2 years experience.

[F._Schubert]

Some more ideas come to my mind.

a) using private properties, we could write some tool that is verfying that there is a single writer to each global. Maybe a good place would be a prebuild hook in the AppBuilder so you verify it for all dynamically loaded vi's as well.

b) using scripting, we might actually write a converter that is replacing all globals with LV2style globals. That way we (with the min 2 years experience) could mess around with globals for the easy use and when the co-worker that is not yet global-proof comes, we automagically convert them all before he sees them...

 

Felix 

[tst]

---

F. Schubert wrote:

a) using private properties, we could write some tool that is verfying that there is a single writer to each global. Maybe a good place would be a prebuild hook in the AppBuilder so you verify it for all dynamically loaded vi's as well.

---

Dynamic VIs are not necessarily available at build time, thus making this feature incomplete.

---

b) using scripting, we might actually write a converter that is replacing all globals with LV2style globals.

---

If a LV2 global only has read-write functionality, it's not any better than a global.

[Intaris]

---

jcarmody wrote:
Does this sound like an application for a Singleton?  I've never tried one before, but I did sleep at a Holiday Inn last night.

---

A SEQ without the "Dequeue" option would be enough.  Only able to get the data via "Preview" (thus not removing it from the Queue) and Bob's your uncle.  And I should know, I have an uncle called Bob.

Shane.

[tst]

---

Intaris wrote: 

A SEQ without the "Dequeue" option would be enough.

---

You mean like a notifier?

The notifier has an additional advantage in that if you want, you can have each place in the code read a new value only once.

[Intaris]

Yeah it could be a notifier also, but then you'd have to block access to the "Send Notification" function to prohibit writes.  But then how to initialise the notifier?

Blocking a dequeue will automatically prevent writes on a SEQ (timeout on subsequent attempted writes).

Shane.

[Ben]

---

Ben wrote:

---

Intaris wrote:

Isn't this kind of easy to do with LVOOP?

A write function which allows only a single execution, otherwise returning an error?

Shane

---

I don't remeber which thread I posted this image too but YES!

Ben

---

A zip of that code ( a LV constant based on LVOOP) can be found in this thread.

Ben

[Broken_Arrow]

---

tst wrote:

If a LV2 global only has read-write functionality, it's not any better than a global.

---

Reminds me of this. (message 35 and 36).

[tst]

---

Intaris wrote:

Yeah it could be a notifier also, but then you'd have to block access to the "Send Notification" function to prohibit writes.

---

Fair enough, although IMO, code which has fake multiple writes is much worse than code which has real multiple writes. The only way this will be acceptable is if the enqueue VI raises a clear error whenever its timeout output returns T (meaning the queue is full).