Jump to content

Request to rename this forum to include "LVOOP" in the name


Recommended Posts

QUOTE(Aristos Queue @ Dec 7 2007, 03:37 PM)

The forum is currently named GOOP. There's an awful lot of posts there about LVOOP. The new GOOP Toolkit blurs the line between these two, but there's still a difference. Can this forum please be renamed to be "GOOP/LVOOP" ?

Nay.

LVOOP is just one aspect of object orientation in LabVIEW. I propose we rename GOOP forum to "Object-Oriented Programming" or just maybe just "OOP". However, maybe there should be a LVOOP subforum, but I'm not really sure yet. That said, if you give us by reference LVOOP then I'll give you all my support on this proposal ;)

Link to comment

QUOTE(Jim Kring @ Dec 7 2007, 08:17 PM)

Nay.

LVOOP is just one aspect of object orientation in LabVIEW. I propose we rename GOOP forum to "Object-Oriented Programming" or just maybe just "OOP". However, maybe there should be a LVOOP subforum, but I'm not really sure yet.

OOP would be ok naming wise, but it wouldn't help with folks who search for "LVOOP" or for disentangling the names.

Link to comment

QUOTE(Aristos Queue @ Dec 7 2007, 07:00 PM)

OOP would be ok naming wise, but it wouldn't help with folks who search for "LVOOP" or for disentangling the names.

Nor would it help folks who search for "GOOP", "OpenGOOP", "dqGOOP", "Functional Globals", etc. Maybe it would be good to have some subforums or categories.

Link to comment

QUOTE(Jim Kring @ Dec 7 2007, 11:23 PM)

Nor would it help folks who search for "GOOP", "OpenGOOP", "dqGOOP", "Functional Globals", etc. Maybe it would be good to have some subforums or categories.

"Functional Globals" --- what the??? Where did this one come from?

At any rate, I conceed OOP or spelling out the acronym would be better generally. I think given the confluence of the various forms of OOP that while subforums might be useful, there'd be an awful lot of top-level posts. So I'm abvivalent about whether or not subforums exist.

Link to comment

QUOTE(Aristos Queue @ Dec 8 2007, 05:12 AM)

"Functional Globals" --- what the??? Where did this one come from?

Functional Globals encapsulate data and functionality in a singleton by reference "class" -- they are one of the first object-oriented programming techniques employed by LabVIEW developers. Check out LabVIEW for Everyone, 3rd ed. Appendix D (pp. 903-912) for more info ;)

Link to comment

QUOTE(Jim Kring @ Dec 8 2007, 11:38 AM)

Functional Globals encapsulate data and functionality in a singleton by reference "class" -- they are one of the first object-oriented programming techniques employed by LabVIEW developers. Check out LabVIEW for Everyone, 3rd ed. Appendix D (pp. 903-912) for more info ;)

FWIW, that's certainly how it always seemed to me.

Link to comment

QUOTE(Jim Kring @ Dec 8 2007, 12:38 PM)

Functional Globals encapsulate data and functionality in a singleton by reference "class" -- they are one of the first object-oriented programming techniques employed by LabVIEW developers. Check out LabVIEW for Everyone, 3rd ed. Appendix D (pp. 903-912) for more info ;)

GAH. They should certainly be one of the first data storage techniques that one learns in LV. But although I suppose they are a form of functionality encapsulation on a piece of data, I wouldn't ever have classified them as "object oriented", especially since the need to code every operation that you want to do on the given (string, number, your-favorite-datatype) is seen as a limitation of such VIs, not a strength.

Your views are warped by your history, my friend. The only tools a caveman has are rocks and sticks, and perhaps he uses one to pound and the other to poke, but let's not equate them to a hammer and nail.

Link to comment

QUOTE(Aristos Queue @ Dec 9 2007, 08:37 AM)

GAH. They should certainly be one of the first data storage techniques that one learns in LV. But although I suppose they are a form of functionality encapsulation on a piece of data, I wouldn't ever have classified them as "object oriented", especially since the need to code every operation that you want to do on the given (string, number, your-favorite-datatype) is seen as a limitation of such VIs, not a strength.

Your views are warped by your history, my friend. The only tools a caveman has are rocks and sticks, and perhaps he uses one to pound and the other to poke, but let's not equate them to a hammer and nail.

I really have to side with Aristos on this one. Encapsulation is one aspect of object-oriented programming, but simply using encapsulation doesn't make something object-oriented.

I've been using encapsulation for years, but that is still a long way from proper OOP.

Shane.

Link to comment

QUOTE(Aristos Queue @ Dec 8 2007, 11:37 PM)

GAH. They should certainly be one of the first data storage techniques that one learns in LV. But although I suppose they are a form of functionality encapsulation on a piece of data, I wouldn't ever have classified them as "object oriented", especially since the need to code every operation that you want to do on the given (string, number, your-favorite-datatype) is seen as a limitation of such VIs, not a strength.

Your views are warped by your history, my friend. The only tools a caveman has are rocks and sticks, and perhaps he uses one to pound and the other to poke, but let's not equate them to a hammer and nail.

Whether or not a tool is object-oriented is not a black and white issue -- tools are object-oriented on a continuum of varying degree. If we think abstractly (which, as we know, is an important skill for object-oriented analysis and design) then we will notice that Functional Globals exhibit shades of the following object-oriented concepts: Class, Object, Encapsulation, and Abstraction. We will also see that the other two concepts of object-orientation, Inheritance and Polymorphism, are not found in Functional Globals. As such, Functional Globals are a tool (albeit not 100% object-oriented) for implementing some object-oriented software designs.

There are almost no object-oriented tools (LVOOP included) that do not limit software developers due to the constraints of the frameworks and the histories of the tools they are written in and the developers who created them. Certainly, Functional Globals are not the best object-oriented tool for LabVIEW developers, but that said, you'd be hard-pressed to find another object-oriented programming technique in LabVIEW with such wide-spread adoption and successful deployment.

Does acknowledging that Functional Globals have object-oriented qualities and understanding their importance today and in the history of object-oriented LabVIEW techniques really make me a Neanderthal? Maybe. But, doesn't the analogy of pounding and poking beg for a Freudian interpretation? "Tool envy" comes to mind ;)

Kring out,

Link to comment

QUOTE(Jim Kring @ Dec 9 2007, 03:13 PM)

Does acknowledging that Functional Globals have object-oriented qualities and understanding their importance today and in the history of object-oriented LabVIEW techniques really make me a Neanderthal? Maybe. But, doesn't the analogy of pounding and poking beg for a Freudian interpretation? "Tool envy" comes to mind ;)

Successful invocation of Freud grants victory (just as invocation of Hitler causes automatic loss). So for the moment I'll grant Functional Globals status as OO tools, subject to review of decision one year from now. :D

Nevertheless, GOOP is an inaccurate name for the forum since GOOP is a specific type of technology (whether it was intended that way or not originally, it is now).

Link to comment

The fact that something used a certain subset of a typical programming technique doesn't automatically make it compatible.

There ARE different techniques to OOP out there people. OOP has become such a sprawling, multi-interpretation term that it has become almost meaningless. One person interprets OOP as meaning this, others as that, others again as something completely different.

A technique using encapsulation and abstraction but without inheritance per se (although it certainly is optional) is Component-based programming.

I think this description fits much better than Object-oriented as the missing inheritance (almost universally thought of as being a key factor of object-oriented programming) is not required.

Just my 2c.

Shane.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.