LVOOP-DVR Name

[jgcode]

Is "LVOOP-DVR" is a little long winded

Does the LabVIEW community have a name for LVOOP-DVR'ing?

Is it too confusing to call it GOOP with Endevo, Sciware, DqGOOP etc already out there?

Was there a name that came up at NI Week 09 from NI?

Or is it too soon yet to have one? Can we vote on one?

With all the flavours it would be to be able to distinguish it when talking about it.

[crelf]

Is "LVOOP-DVR" is a little long winded Does the LabVIEW community have a name for LVOOP-DVR'ing?

When pronounced, el-voop-dee-vee-are doesn't take too long

[jgcode]

When pronounced, el-voop-dee-vee-are doesn't take too long

Just on a side note do people pronounce LVOOP:

el-ve-oop

or

el-voop (as Crelf above)

Is there correct way?

I may have been saying it wrong for the last few years

[Francois Normandin]

I always say it el-vee-oop.

Though I noticed at NI Week that people more often use el-voop.

(let's blame it on my weird french canadian accent )

[crelf]

I always say it el-vee-oop. (let's blame it on my weird french canadian accent )

Shouldn't that make it el-vee-oop-eh?

Aristos calls it el-voop, so I figured he defined it so I should follow suit.

[Yair]

How about DROOP?

[Francois Normandin]

Shouldn't that make it el-vee-oop-eh?

I wouldn't know. [Political comment] I'm not really considered a canadian. [/Political comment]

Well, if AQ says so... eh?

[Jim Kring]

Is "LVOOP-DVR" is a little long winded

Does the LabVIEW community have a name for LVOOP-DVR'ing?

Is it too confusing to call it GOOP with Endevo, Sciware, DqGOOP etc already out there?

Was there a name that came up at NI Week 09 from NI?

Or is it too soon yet to have one? Can we vote on one?

With all the flavours it would be to be able to distinguish it when talking about it.

I have a feeling that people will/should just call this "native OOP" or "LVOOP" and start refering to DVR's as "references" (and DVR's to LVOOP objects as "object references"). This is the "right" (sanctioned) way to do OOP in LabVIEW, so there's really no need to qualify it. But, if you must qualify it, then the term "native" seems fitting.

[John Lokanis]

How about we simplify it and call it G++ ??

Personally, I like calling it Lab-voop, as in:

"I am learning to write Lab-voop code in LabVIEW."

[crelf]

Well, if AQ says so... eh?

eh!

How about we simplify it and call it G++ ??

Because LabVIEW isn't G

...start refering to DVR's as "references" (and DVR's to LVOOP objects as "object references").

Sounds good to me.

[Anders Björk]

eh!

Because LabVIEW isn't G

Sounds good to me.

I vote for G# Darn it exists.

How about DROOP?

Is that AQ?

Edited August 17, 2009 by Anders Björk

[Aristos Queue]

The following was written on my whiteboard at my desk for most of the time we were developing LVOOP:

El Voop == Spanish for strength!

Le Voop == French for style!

Al Voop == Arabic for quality!

LVOOP == LabVIEW for class!

And for the record, we didn't have any way of pronouncing "LVOOP-DVR" during development because DVRs are not specific to objects.

[jgcode]

And for the record, we didn't have any way of pronouncing "LVOOP-DVR" during development because DVRs are not specific to objects.

Far enough, but did anyone internal coin a phase when they put the two together?

Also what do you prefer?

Did you/where you involved in creating the DVR's?

[Jim Kring]

Far enough, but did anyone internal coin a phase when they put the two together?

Also what do you prefer?

Did you/where you involved in creating the DVR's?

My thinking: LVOOP objects are "data values", so a DVR to an LVOOP object is an object reference.

[nhollenback]

My thinking: LVOOP objects are "data values", so a DVR to an LVOOP object is an object reference.

I concur, it is an object reference.

But... I like acronyms and we've needed one for this amazingly powerful toolset (LVOOP and now the DVR). Why not just VOOP. And when I'm coding it I'm VOOPing. And those who are real good at it are SOOPer VOOPers. And then LAVA can be come LAVOOPA.

Okay, maybe it's just an object reference

[tkuiper]

Just don't do it so much that you get the VOOPing cough!

Edited August 18, 2009 by tkuiper

[Norm Kirchner]

So far I have fought the act of sounding silly by saying

Labvoop or lavoop or anything of the sort.

It makes it much easier just to say

I'm going to develop my application with 'native classes' or 'native objects'

and then it just becomes a matter of native class references or native object references

although VOOP is about as close as it gets to something that I would actually bring myself to say with a hope of someone knowing what I'm talking about.

I suppose if I really want to, I'll just make a whitepaper doc on ni.com and that'll be the end of the discussion ~,~

[nhollenback]

So far I have fought the act of sounding silly by saying

Labvoop or lavoop or anything of the sort.

It makes it much easier just to say

I'm going to develop my application with 'native classes' or 'native objects'

and then it just becomes a matter of native class references or native object references

although VOOP is about as close as it gets to something that I would actually bring myself to say with a hope of someone knowing what I'm talking about.

I suppose if I really want to, I'll just make a whitepaper doc on ni.com and that'll be the end of the discussion ~,~

So, I think the object is the entity that is actually created at runtime. And the reference would be to the object. So as Jim Kring said, object reference is the best technical term.

The class refers to the collection of the .lvclass file, with the definition of the private class data, and the methods that act on that data.

And, I think that with the maturity and prevalence of LVOOP, we are at that stage where we can drop the term "native." When I use the term class, it now implicitly refers to LVOOP

So perhaps it is VOOP and VOOP'R.

And since when did you shy away from silliness? (I probably not doing a good job of getting an invite to the editorial board for your white paper)

[jgcode]

So, I think the object is the entity that is actually created at runtime. And the reference would be to the object. So as Jim Kring said, object reference is the best technical term.

The class refers to the collection of the .lvclass file, with the definition of the private class data, and the methods that act on that data.

And, I think that with the maturity and prevalence of LVOOP, we are at that stage where we can drop the term "native." When I use the term class, it now implicitly refers to LVOOP

So perhaps it is VOOP and VOOP'R.

And since when did you shy away from silliness? (I probably not doing a good job of getting an invite to the editorial board for your white paper)

IMO I think it is very important to have a defined term so it can be mentioned and people know exactly from the get go, the topic (whatever that topic is, design patterns, oop etc...).

Alright - cool then in summary...??

We are still LVOOPing regardless of using either the native byValue (original LVOOP) or byRef (DVR with LVOOP) so if it is agreed by the big wigs I am going to call them native object references, or object references for short.

Can we get a NI whitepaper?

Thanks

Edited August 18, 2009 by jgcode

[nhollenback]

IMO I think it is very important to have a defined term so it can be mentioned and people know exactly from the get go, the topic (whatever that topic is, design patterns, oop etc...).

Alright - cool then in summary...??

We are still LVOOPing regardless of using either the native byValue (original LVOOP) or byRef (DVR with LVOOP) so if it is agreed by the big wigs I am going to call them native object references, or object references for short.

Can we get a NI whitepaper?

Thanks

Nice summary!! I think everyone would concur on the need for a defined term. We used to have LV2-Style globals, action engines, VIGs, USRs and now we simply have FGVs

Here is a thought from a discussion I had last night with someone who knows nothing about LabVIEW. Perhaps in the quest for the perfect "name" we focus less on OOP and more on a name that reflects the benefit of the technology. For instance, the dynamic dispatch just rocks. In essence we now have intelligent wires. What if we follow that line of thinking and see what pops. Perhaps I'll have a chance to return to last night's conversation.

Regardless, "object reference" was in several comments above. I tend to make the mistake of overly tying DVR with LVOOP when much of the LabVIEW community will use them without classes.

I will check "on high" with the "big wigs" and at least weave a few paragraphs into the Advanced Architectures in LabVIEW course.

[vugie]

I don't know whether word "voop" is not too meaningful...

[jgcode]

I will check "on high" with the "big wigs" and at least weave a few paragraphs into the Advanced Architectures in LabVIEW course.

I see the new Advanced Courses are out!

http://sine.ni.com/nips/cds/view/p/lang/en/nid/207398

http://sine.ni.com/nips/cds/view/p/lang/en/nid/202648

Well done to you and Scott.

I don't know whether word "voop" is not too meaningful...

Dude, Kudos for that.

"Dude, why did you just voop my girlfriend?"

[Christian_L]

Nice summary!! I think everyone would concur on the need for a defined term. We used to have LV2-Style globals, action engines, VIGs, USRs and now we simply have FGVs

Here is a thought from a discussion I had last night with someone who knows nothing about LabVIEW. Perhaps in the quest for the perfect "name" we focus less on OOP and more on a name that reflects the benefit of the technology. For instance, the dynamic dispatch just rocks. In essence we now have intelligent wires. What if we follow that line of thinking and see what pops. Perhaps I'll have a chance to return to last night's conversation.

Regardless, "object reference" was in several comments above. I tend to make the mistake of overly tying DVR with LVOOP when much of the LabVIEW community will use them without classes.

I will check "on high" with the "big wigs" and at least weave a few paragraphs into the Advanced Architectures in LabVIEW course.

I would look at other programming languages and see what they call their classes and objects.

Looking at C++, it seems the term class and object are pretty popular. So if LabVIEW has a native class and object, why not call them class and object? (It's not like were calling an integer an LVINT.) Since the wire representing a native object in LabVIEW is 'ByValue' then use the appropriate modifier for a reference to an object, like object reference or object DVR. I guess a single element queue containing an object would be an object QR. We may still need to differentiate between DVR and SEQ containing an object.

[jgcode]

I would look at other programming languages and see what they call their classes and objects.

Ahhh... But LabVIEW isn't just any other programming language!

And it's (native) implementation of OOP is very unique (thanks AQ )

Should we use standard terms of other languages?

I have seen arguments for this, and against this, on the forums

Does it hinder or help people learn, who may have or may not have other programming experience???

But I tend to agree - the term object reference sounds clear and concise.

Great point on LVOOP-DVR vs LVOOP-SEQ !!

I am thinking that LVOOP-DVR is the more native approach, as I can see DVR being the future of byRef OOP in LabVIEW, and as such warrents the term native object references IMO.

What do others think?

[Christian_L]

Ahhh... But LabVIEW isn't just any other programming language!

And it's (native) implementation of OOP is very unique (thanks AQ )

Should we use standard terms of other languages?

I don't see why either of these would cause us not to use standard terminology for what seems like standard programnming features.

If we want LabVEW to be accepeted as a programming language, which at least some strive for, then we should use programming terminology when talking about it.

I have seen arguments for this, and against this, on the forums

Does it hinder or help people learn, who may have or may not have other programming experience???

For people without programming experience, I don't think it makes any difference what we call it, as the name won't mean anything to them either way and they have to learn the concept.

Should it be a GHEER-MLB or a widget pointer? Which of these would you rather learn how to use?

But I tend to agree - the term object reference sounds clear and concise.

Great point on LVOOP-DVR vs LVOOP-SEQ !!

I am thinking that LVOOP-DVR is the more native approach, as I can see DVR being the future of byRef OOP in LabVIEW, and as such warrents the term native object references IMO.

What do others think?

But the point should be to get away from calling it native anything. Either is native and you don't need to call it that, or it isn't native and needs a different name.

Should they be NLCs* or just classes?

*Native LabVIEW Classes