WORM Global

[RayFarmer]

You could change it so that you dont have to specify Add | Read. Just the Global name and its value or return its value.

First time its delete all.

Second time and specifying Global for the first time, then it adds

Next time and specifying Global and it exist and the Value In is empty then it returns the Value.

If the Value In contains data then and error is generated because its trying the change the stored value.

Regards

Ray Farmer

[tbob]

Ray "Mr. TestStand" Farmer:  Good to hear from you in this forum.

So you are saying that if the user specifies a value, then the add function should be implied.  If a value is specified and the name already exists, then it is in error.  If the user does not specify a value, then this implies a read function.  Very good point.  One less input to send.

Does anyone else think this is the way to go?  It is a good idea, but I'm undecided.  I would like to hear some pros and cons.  My pro would be one less input to wire.  My con would be that it takes a little more effort to determine the action when looking at the code.

[tbob]

Here is the modified WORM_Global as suggested by Ray Farmer.  After playing with it, I like it.  First call still does delete all and then adds first value (if name and value in are present), all in one.

[Ray.R]

I haven't looked at you latest WORMs, yet, but I think RayF was on the right track.

Since the first time you use it, it would be to input all the .... euh.. "global" values, then you just wire that funtion, so a single terminal would do as an input.  Afterwards, wiring something to the input would be futile.  However, you can always read.  If you read upon the first time, then you just read nothing and serves whoever right for misusing it.  (it's a bit early in the morning... waiting for the tea to finish infusing, so the braincells are still asleep.  hopefully what I wrote made sense. I need to work on mind-melding techniques 😉 )

[Albert.Geven]

I completely agree with the automatic read if no value is supplied.

Now it is a real WORM

[Albert.Geven]

What about the following idea.

To make a WORM without variants.

Simple polymorphism can do this job but the problem is that duplicate names can occur.

We could of course check in a simple string name WORM for these duplcate names and issue an error before creating the var of the given type.

It makes the receiving program much easier to use the var.

[tbob]

---

Albert Geven wrote:

What about the following idea.

To make a WORM without variants.

Simple polymorphism can do this job but the problem is that duplicate names can occur.

We could of course check in a simple string name WORM for these duplcate names and issue an error before creating the var of the given type.

It makes the receiving program much easier to use the var.

---

Can't store different data types in a shift register unless you use a cluster.  But you can't add to a cluster at runtime.  That is why I use an array of variants.  Any data type fits, and you can add to it during runtime.

[Albert.Geven]

In fact in a polymorph vi you don't store different datatypes in a cluster, in each polymorph vi you only have the shiftregister for that type.

The only problem in programming is that for each separate type you need a separate implementation.

So what I think of is a polymorph base vi for which the compiler places the call to the actual implementation and that actual implementation checks in a common string wormglobal (or special WORM) for name collisions.

[tbob]

---

Albert Geven wrote:

In fact in a polymorph vi you don't store different datatypes in a cluster, in each polymorph vi you only have the shiftregister for that type.

The only problem in programming is that for each separate type you need a separate implementation.

So what I think of is a polymorph base vi for which the compiler places the call to the actual implementation and that actual implementation checks in a common string wormglobal (or special WORM) for name collisions.

---

You would have to have a separate vi for each data type.  You would have to search for a name in each vi.  To me this is very cumbersome compared to using variants.  I would rather have just one vi.  There is nothing so wrong with using variants that you would have to go through so much trouble to avoid using them.

[RayFarmer]

Maybe you could use LVGOOP to handle this and have the base method store the data as a variant with higher level (polymorhic VI handling the different data types) That why you could keep the one search vi.

regards

RayF