Still not making sense.

[Joe Byrne]

I'm back to trying to figure out the whole OOP thing. Somehow I get the feeling that there is more to it than what I can see on the surface, but my general opinion is still in the "so what" category.

For example, Bob's comment in the opening "OOP" discussion:

For example, a string array containing names and addresses (data) might be packaged with a subroutine (code) that displays a popup dialog to edit the data, another subroutine (code) to print mailing labels, and so forth. That's a great candidate for an object.

Why would these functions be better off as objects rather than the traditional FUNCTION? There must be a real-world value to writing these things as objects, but I can't see what that value is.

I'm hoping someone can shed some light on this for me. Perhaps then, the overall value of OOP may make more sense to me.

[Michael Mattias]

For your own projects/products, OOP is a source-code level tool. IMO it offers few benefits for those who already have developed their techiniques for code and/or data isolation. For those migrating from object-oriented languages, this option makes that migration a lot less painful than it might otherwise be.

For redistributed code, it is a packaging tool... makes the product more appealing to users of object-oriented languages such as Delphi or Visual Basic, many such programmers being wimps when it comes to using dynamic link libraries.

"OOP" versus "conventional syntax" also has a tremendous potential to launch some awesome BBS/Newsgroup "Flame Wars", much as the use of "GOTO / GO TO " does amongst in both COBOL and BASIC-language programmers.

[jcfuller]

Joe,
If the light bulb has not gone off after downloading and examining the many examples on the forum then you probably will find little use for it.

James

[Michael Mattias]

FWIW, as a new USER of a COM library (ADO), I find the discussions of how objects are created and used, both in the Win/9x help and here quite useful to understanding how that "black box" actually works.....

Don't see myself creating any classes in the forseeable future, but then again my API sales have not been all that great the past six months.. maybe if I package them as COM libraries I shall have more success...?

[Joe Byrne]

Thanks Michael. Your comments seem to confirm my beliefs.

Joe,
If the light bulb has not gone off after downloading and examining the many examples on the forum then you probably will find little use for it.
James

James: You are probably right. The first hurdle I've tried to overcome, and am still not finding an answer to, is the "why" question. If I can't "see" a reason for something, I can't formulate the required tasks in my mind. Assuming Michael's response is accurate (which I believe is the case) then there is no compelling reason to switch to OOP unless one wants/needs to be doing the same thing in a more "accepted" way. Not that the new way is any better, just has a broader audience I suppose.

Since all of my software is currently targeted to a specific customer or vertical market (meaning very little if any 'out-side' changes are ever done), then I'm thinking there is no real benefit to me to change my style to accommodate OOP.

Of course, if someone has a compelling reason why this train of thought is inaccurate, I'd still love to hear that side of the argument.

[Michael Mattias]

Just for your own edification...

Since I started USING the ADO library, I have learned there is simply a TON of "COM-interface" support tools available for Windows' systems.

So even if you are not planning on CREATING COM libraries, learning how to USE them can IMO open many windows of opportunity (no pun intended).

MCM

[Nick Luick]

If the code & data is packaged in a COM object how does one go about modify the data without a external source ?
Or is only the data types and space reserved in COM object much like TYPE statments ?

[jcfuller]

Joe,

Here is an example of encapsulating the new DISPLAY OPENFILE with a class.
I did it because:
1. I am lazy
2. I can never remember the parameters and/or their order.

So I let the CREATE METHOD set Default parameters. If I want changes to the default it's very easy to do.

James

'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
'SED_PBWIN
#COMPILE EXE
#DIM ALL
'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
'Property Macros
#IF NOT %DEF(%Prop_MACROS)
    %Prop_MACROS = 1
    MACRO PropGet(PropName,PropType)=PROPERTY GET PropName() AS PropType:PROPERTY=PropName:END PROPERTY
    MACRO PropSet(PropName,PropType)=PROPERTY SET PropName(BYVAL param AS PropType):PropName=param:END PROPERTY
    MACRO PropGetD(PropName,PropType,DispId)=PROPERTY GET PropName <DispId> () AS PropType:PROPERTY=PropName:END PROPERTY
    MACRO PropSetD(PropName,PropType,DispId)=PROPERTY SET PropName <DispId> (BYVAL param AS PropType):PropName=param:END PROPERTY
#ENDIF
'------------------------------------------------------------------------------
'Return Nacros
#IF NOT %DEF(%RET_M_MACRO)
    %RET_M_MACRO = 1
    MACRO Ret_M(RetVal) = METHOD=RetVal:EXIT METHOD
#ENDIF
#IF NOT %DEF(%RET_F_MACRO)
    MACRO Ret_F(RetVal) = FUNCTION=RetVal:EXIT FUNCTION
    %RET_F_MACRO = 1
#ENDIF
'------------------------------------------------------------------------------

'******************************************************************************
CLASS cDisplayOpenFile 
    INSTANCE sFileName,Folder,Filter,Start,DflExt,Title AS STRING
    INSTANCE hParent,Flags AS LONG
'Default entries set in the CREATE METHOD 
    CLASS METHOD CREATE
        Filter = CHR$("All Files",0,"*.*",0)
        Flags = %OFN_EXPLORER OR %OFN_FILEMUSTEXIST
        Title = "Select File"
        Start = ""
        Folder = CURDIR$
    END METHOD

    INTERFACE iDisplayOpenFile : INHERIT IUNKNOWN
        PropSet(Folder,STRING)
        PropSet(Filter,STRING)
        PropSet(hParent,DWORD)
        PropSet(DflExt,STRING)
        PropSet(Start,STRING)
        PropSet(Title,STRING)
        PropSet(Flags,DWORD)
        METHOD GetName() AS STRING
            DISPLAY  OPENFILE hParent,,,Title,Folder,Filter,Start,DflExt,Flags TO sFileName
            METHOD = sFileName
        END METHOD
    END INTERFACE
END CLASS
'==============================================================================
FUNCTION PBMAIN() AS LONG
	LOCAL oDop AS iDisplayOpenFile
    LOCAL sFile AS STRING
	oDop = CLASS "cDisplayOpenFile"
	IF ISNOTHING(oDop) THEN
		?" No oDop"
		Ret_F(0)
	END IF
	'Call it with the default parameters
	sFile = oDop.GetName()
	?sFile
	'Change the filter 
	oDop.Filter = CHR$("Basic Files",0,"*.bas;*.inc",0,"All Files",0,"*.*",0)
	sFile = oDop.GetName()
	?sFile
	
END FUNCTION

[Joe Byrne]

James,

Ok, but that still doesn't answer my primary question.

Why is this method better than doing the same thing in a standard FUNCTION?

I keep an include file with a number of generic SUBs and FUNCTIONs. By simply including this file, all my 'standard' routines are readily available to me. I'd assume that the same thing would have to be done regardless of whether the code is procedural or OOP, right?

Assuming one does not intend to "publish" their code for others to use, is there an advantage to OOP or is it mostly style?

I can understand Michael's point about understanding OOP from a USE perspective, but again, I can't say that I've ever run into a situation that required COM access. Perhaps that will change as more PBers start using OOP, but for now anyway, it seems to me to be more of a preference thing than a real advantage.

Is that a fair assessment?

[jcfuller]

Why is this method better than doing the same thing in a standard FUNCTION?

Joe,
I explained it above. I don't have to remember/lookup parameter order. To me this is a VERY BIG reason at my age.

James

[Joe Byrne]

Joe,
I explained it above. I don't have to remember/lookup parameter order. To me this is a VERY BIG reason at my age.
James

Ok, fair enough.

[Chris Holbrook]

Is that a fair assessment?

One thing that has made a big difference for me is having these INSTANCE variables which are accessible to all the methods in my objects, but invisible from the outside, private variables in other words. This reduces the number of variables, pointers to UDTs, etc which have to be passed between functions in the non-OOP model, resulting in fewer "moving parts" (I think of parameter lists, conditional statements, flow control statements as "moving parts"), which can only result in greater reliability.

[John Strasser]

James,

Ok, but that still doesn't answer my primary question.

<snip>

Is that a fair assessment?

Hi Joe,

It may be a fair assessment. What I've found usefull about using OOP vs POP (Plain Ole Procedural) is more dependent upon the nature of the project than anything else.

If, when I think about the project I find that I'm thinking about "things" I'm more likely to use an OOP based approach. If I'm writing an app where I think about "doing" then I rarely use OOP.

Example - In my old world I used to write process simulations and control systems. Which means I often thought in terms of "pieces of equipment" or in terms of "plugs of gas/fluid" as they moved through a duct or pipe.

By designing a class library around these "things" it made it easier for me to design and support various "systems". Whether these systems were in one program or in several in different projects. It also dovetailed very nicely with the entire chemical engineering mindset (my original degree) of "unit operations" (meaning a pump is a pump is a pump - regardless of how it works internally - so we would black box everything)

So one class library I would create (obviously <grin>) would be "pump".
First I'd create a "generic" base class which would define the interface. Then every speciic pump would be decended from that base. Which means that if I had 2 pumps (A and B) and I needed the output pressure I would call *the exact same function* "pump.pressure_out()" in any place where I needed that value. So I would pass a pointer to either pumpA or pumpB.

The way that would work was that (since pumpA and pumpB were both class"pump") I could over ride the pressure_out function within each child class. Then a "pointer to a class pump" could point to ANY class decended from class pump. And it would then call the proper version of the function according to which pump (A or B) I was "pointing to". I didn't have to remember to explicitly call the right one.

Another advantage (as compared to a type or structure which would just hold the variables associated with my "object") is that (at least here in PB) classes can hold dynamic strings. So, if you've ever bitched (as I have) about wanting to include dynamic strings in a user defined type just create a class and it's a typedef with a dynamic string.

When I started OOP programming (way back when) my reaction was identical to yours. Then I had a project where I was dynamically creating and destroying structures (in C, typedefs in PB) constantly and the ability to automate that (with constructors and destructors) made my life a LOT easier. After that I found uses for the other OOP features.

Now, when I think about using OOP my first thought is "will I be need to create a class library"? And if the answer is no I probably don't need OOP.

BUT if I have a number of different typedefs in a program and I want to save them in ascii or random access files I might turn them into classes just so that I can have the file i/o as part of the class (not because I want a "library") and type "myclass.save" or "myclass.read" or "myclass.print". Sort of a fire and forget way to organize things.

If I was going to give advice about whether to use OOP or not, my suggestion would be this: If you use TYPEDEF *anywhere* in your programs, they are a candidate for "OOPing". Because a "TYPE" is essentially a limited form of "Class".

Hope this helps.

JS

[Fred Harris]

Joe,

I think there is a whole additional aspect to it than a strict comparison of calling a function or making an object method call. The additional aspect concerns the development environments usually associated with the major Object Oriented Programming languages such as Microsoft’s Visual Studio product line. If you have never made extensive use of such products then trying to describe their use in programming is about like trying to describe color to person who is color blind.

Let me give a specific example of a fairly common task that a programmer might face that has fairly little to do with how a function or object is invoked or programming paradigms. Lets say a project needs to be started and we have two programmers starting the project. The 1st programmer is Frank and he uses strictly procedural languages like C or PowerBASIC before any of the COM/OOP features were added. The 2nd programmer is Larry and he’s OOP all the way and uses something like VB6 or .NET.

The project that needs done needs a grid on the Dialog as the 1st thing to do. So, what is to be done? Well, Frank, the procedural programmer, he knows just what to do because just recently he bought himself a new fangled grid control and has lots of good documentation for it. So he opens up his help file for the grid and listed there are all the functions, Types, and Messages that the grid uses or handles. Immediately his eye catches sight of a CreateWindow() function and he jumps to that. There he can see how he must fill out the parameters for this particular function call so as to get the grid on his dialog. He particularly notes that some of the parameters are specialized in ways particular to the grid; for example, the window caption parameter is modified to accept a very long and cryptic string that will contain all the column widths and captions for the grid’s columns. He further notes that a special type was created containing grid setup information, and an object of this type must be created in whatever function he uses to create the grid in his program. This type contains such info as the number of columns, number of rows, row heights, etc. A pointer to this type has to be passed as the last parameter of the CreateWindow() call

Having looked over all this he then checks out some of the sample files that came with the grid. Since Frank is an Sdk style C or PB programmer he finds an Sdk sample program and begins to study that. He sees that in order to use this new grid control he has to call an InitiateGrid() function, and he decides to put that in WinMain(). Then he sees a big Select Case / switch construct in the Window Procedure and there can be also seen many of the messages the grid sends to its host. He studies all this for awhile and finally decides to see if he can get the thing working for himself. He copies one of his Sdk templates to a new code window and starts coding. He sets up all the members that go in the grid setup type and he constructs the bizarre caption string that contains all the column captions for the grid along with column widths and other cryptic symbols. The first time he tries to run the code he gets the expected and virtually certain compile error message. Not being alarmed at all (he knows this is typical and it will be something simple – Frank’s a very competant coder) he sees he forgot to include the header file for the grid! So he plugs onward. Being a competant Sdk style programmer he does manage to finally get himself a decent starter program working with one of his new grids on it but by this time, after having studied the docs, the functions, the messages, the types, etc., etc., the afternoon is just about gone. He started around noon.

Now lets see what Larry does. Its around noon by Larry’s clock. Larry has only been programming for a little while. When he was in college he had to learn a little VB programming for a course he had to take. Anyway, Larry fires up VB6 and in a second or two he sees a blank Form (dialog) in the VB design environment. He knows that ‘special’ controls like grids are not automatically included in the default toolbox VB presents the programmer with, so he goes up to the main menu and selects

Projects >>> Components

Immediately a dialog pops up which lists in a listview/listbox type control all the COM components installed on his computer. There are seemingly hundreds if not thousands of them - each brimming with some unique capacity. He scrolls down till he reaches the ‘Ms’ and there finds the…

Microsoft FlexGrid Control 6.0 (sp3)

He puts a check mark next to it, hits the ‘Apply’ button, and dismisses the dialog. Now the grid control shows up on his ‘Toolbox’ with the other controls such as text boxes, list boxes, etc. He drags the grid icon to his form and releases the mouse. Immediately a representation for the grid shows up on the form (dialog). He clicks the ‘Run’ button and the program starts and runs but the grid only has the default settings of two rows and two columns. This is no good cuz his project will need about 8 columns and quite a few rows. So he opens up the ‘Property Window’ and locates the grid control which at this time has the default name ‘MSFlexGrid1’. He changes the name in the Property Pane to grdClients, sets the ‘cols’ property to 8 and the ‘rows’ property to 400. He runs the program again and now it looks about the way he wants it. Its about five after twelve now. He spends the rest of the afternoon coding the application. When he is writing the code, all he has to do is type the words…

grdClients.

…in his code editor (VB) and immediately the intellisence popup appears listing every medhod and property exposed by the control. He doesn’t know what most of them do, but by guessing at likely choices he is able to usually find what he needs for whatever he is doing. Occasionally he may need to check the docs for something. By the time the afternoon is over not only does Larry have a working grid control on his Form/Dialog, he has the whole utility program done and ready to show the boss.

The above description I have just presented is not far fetched at all, and it doesn’t really have much to do with the underlying theory of object oriented programming verses procedural programming. For whatever reason OOP coupled with component architectures seems to lend itself to the creation of these design environments which make programmers extroadinarily productive. For this reason I believe there is more to it ( OOP ) than simply arguments over procedural vs. oop programming theory (although there are some good arguments there!).

Naturally, there are a lot of sides to the issue. Larry would be lost without his Visual Studio (or a clone) design environment. He’d probably struggle to get a “Hello, World” out in C if he had to. He’s probably clueless about Byref/Byval parameter passing mechanisms.

How many times in these forums have we seen a new name pop up we’ve never seen before; its his/her first post; just purchased PowerBASIC coming from a VB background; and he/she just can’t get an *.ocx to run, or text out of a textbox, or maybe can’t even get a textbox on a dialog? All these things are essentially manifestations of the same basic thing just presenting themselves in different manners.

What seems especially maddening to those of us who have spent untold hours pouring over programming documentation is that many of these newcomers don’t seem to share the same mindset. I think it’s a combination of the RAD (rapid application development) design environments coupled with powerful OOP implementations that allow even beginners to create powerful applications without too much thought. When such folks hit a procedural language where you start by typing in includes and finish by typing in code having done nothing but typing in code all along the way, well – ‘and how do you get a textbox on the form? RTFM!

So, completely aside from the issues of programming theory, OOP in conjunction with component architectures, i.e., ‘black box’ technologies, have and are rewritting the programming world. In thinking about the future of where programming is going – perhaps creating some kind of artificial intelligence like we see in sci-fi flicks, I’m pretty sure that kind of coding isn’t going to be done at the level of MOVing bits around in bytes. Its going to be about OBJECTS.

For myself I’ve given up on Microsoft Visual design technologies. It might seem like I should be a VB programmer being as one might read into my Frank vs. Larry description that I like Microsoft stuff. I really like using OOP and component technologies in my coding which involves PowerBASIC and C++. As many others here have stated, it seems to help. I wouldn’t give up on it. Just work into it slow would be my advice. What can really make it look a lot more attractive is when you discover some kind of control or functionality you would really like to use in one of your projects, and then find out it is a COM object.

[Joe Byrne]

John & Fred,

Good insights! Thanks.

I more-or-less grew up with PB as it was my first choice moving from the mainframe and mini world to PCs. I never liked VB, installed VS 2005 and played with it for all of 20 minutes, and always came back to my beloved PB

I don't normally use TYPEs, but next time I do, I'll look at the possibility of trying an OOP method instead.

I am mildly afraid of running into a situation where I will want a 3rd party product only to find that its available only in "COM" format, which is the only reason I've spent any time at all on PB OOP. I suppose one can't buck the system forever, but I'm amazed at all the buzz around OOP. It still seems to me to be more fashionable than functionalble....but then I remember thinking the same about SQL when I first heard about it

Thanks again for the time to post your comments. I do appreciate them greatly!!

[John Strasser]

You're welcome

Fwiw - I never really got into VB either. And visual C/C++ was a PITA. Especially compared to the various Borland flavors.

John

[Trevor Lane]

If you have a project, and you are the only programmer on the project then it is just a question of style. Objects do make code easier to understand when you are used to it. But then it would be easier for me to understand French if I learned it??? I just dont want to or see the need?? same boat??

However if your project is being programmed by a team it is easier to encapsulate the code you write in an object and just give that object to your fellow programmers. Your object might do some really complex task that you do not want to teach your colleagues a whole API. Just giving them an object is so much easier for them.

Writing your code in objects is really to benefit other programmers who use your code. Not end users; and if you understand procedural programming to the nth degree probably not easier for you either. But I would advocate objects all of the time. I have been authoring objects in VB6 (and putting them into DLLs MM) for a long time now. I just give my DLLs to my colleagues and they benefit from my work (and I theirs) much easier than putting functions into DLLs and teaching them a new API.

[Michael Mattias]

If the code & data is packaged in a COM object how does one go about modify the data without a external source ?

You don't.

Which, I believe, is the whole point: Thou Shalt Not Modify Data Except Via the Approved Methods. (and in this case, "Method" can be EITHER Figurative OR Literal!)