LVOOP-DVR Name

[jgcode]

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.

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 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

I am for one am *proud* that LabVIEW has native object references!

And I don't think anyone is asking to complicate things more (e.g GHEER-MLB)

We are just asking for a (as in one) defining, LabVIEW universal term

I don't see the point in having a bunch of names to describe the one thing, or people creating there own (e.g. NLCs)

That IMO, will lead to confusion in the long run.

The fact is LVOOP with DVRs are in LabVIEW which means they are by definition native.

If using native helps distinguish from other flavours of object references (Endevo, Sciware, dqGOOP, SEQ, homemade etc..) then, that will just lead to clarification.

But thats should be up to the authors and/or the LabVIEW community to decide.

Which was the motivation behind creating the topic (that I was interested in what people have to say)

And well if its good enough for the authors to describe them like this...and the community agrees, than who am I to argue?

LabVIEW has mechanisms for creating references to data – uninitialized shift registers, global variables, single element queues – but the user must do more work to utilize these mechanisms than he or she would have to if we had a native by-reference syntax

http://zone.ni.com/devzone/cda/tut/p/id/3574

There is also a great section on the vocabulary in the LabVIEW Object-Oriented Programming: The Decisions Behind the Design - What considerations were given to vocabulary choice? - if people haven't read it, its a great read. LabVIEW is not C++ or JAVA, while it is nice that there is transparancy across languages, it will never be 100%, and needs not be, as LabVIEW will do things its own way - which makes it a unique language - and thats why I love to use it.

There were other smaller discussions on other terms. The chosen vocabulary of OO is a feature as much as any actual aspect of the user interface. In order to make OO accessible, every new concept had to be challenged. We could not assume that the C++ or Java name for a feature was the right name for LabVIEW

http://zone.ni.com/devzone/cda/tut/p/id/3574

[Daklu]

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???

Diverging from commonly accepted OOP language is a big mistake IMO. There are lots and lots of books available on object oriented programming. There are no books available on Labview object oriented programming. Anyone who wants to learn how to do OOP in Labview is going to have to read one of the books that focuses on another language. Introducing different terminology confuses the issue and becomes an obstacle to learning. (Heaven knows it's already hard enough to translate design patterns into Labview.)

[jgcode]

Diverging from commonly accepted OOP language is a big mistake IMO. There are lots and lots of books available on object oriented programming. There are no books available on Labview object oriented programming. Anyone who wants to learn how to do OOP in Labview is going to have to read one of the books that focuses on another language. Introducing different terminology confuses the issue and becomes an obstacle to learning. (Heaven knows it's already hard enough to translate design patterns into Labview.)

Great point!

I was not stating an opinion wither way, but I do understand its not going to hold 100% of the time - obviously with unique features (e.g. dynamic dispatching, and by value approach) and consequently a unique implementation - that are different from other languages (namely C++ and JAVA). I also guess thats why we have UML so that we can create objects in a universal language, abstracting the implementation (of language). But most of the previous vocab of LVOOP would have been out of the communities' control.

I guess with the Ideas Exchange we now get more of an input (if anyone is listening )

[Eric Desbiens]

Be aware: Reference types should be used extremely rarely in your VIs. Based on lots of looking at customer VIs, we in R&D estimate that of all the LabVIEW classes you ever create, less than 5% should require reference mechanisms. If you find yourself doing more than that, think about ways to use more by-value classes, because you are almost certainly needlessly costing your self performance.

Base on NI warning, I suggest OOPS... I did it again!