Borrowing from Object Oriented systems

[AndrewM]

I don't want to start any flame wars and I have got the message that Fred has said no to OOP. This is just a discussion about my personal experience with the procedural vs OOP topic. So far I have not created any apps in PB, I have only run a lot of sample code to test all of the features that I might want to use. My discussion is based on ms-access experience where both procedural and OOP programming styles are supported. The big issue with other threads on this topic is that people like me who are non-university trained programmers can' t pick up assumed knowledge that underlies most of the debates on this issue. There is very little discussion of the pro's and con's of OOP and this is what I am looking for as it will help me learn and define times when OOP is really needed. I would appreciate it if some people would point out specific examples in PB where they get stuck without OOP. I accept that choosing another language is probably the best solution. Feel free to correct me if I am wrong with the following.

First of all, I would like to point out the advantages of procedural programming (PP):

• With PP find that I can just start, I don't have to have a complete algorithm design in my head. With OOP, you need a better conceptual understanding of the whole task and how split a task up into its components before you start. As such OOP can be harder to learn.
• Debugging OOP can be harder as inspecting variables within objects in ms-access is not possible when an app hangs (due to encapsultation?). I have to put break points in the class code if I want to debug a class interactively.
• From a theoretical perspective, it can be hard to validate OOP code as objects can be little black boxes subject to lots of influences which can interact in unpredicted ways. In mission critical disciplines where certainty is required the functional programming style is possibly better. As far as I understand things functional programming is just PP with lots of user defined functions.

The following section provide the reasons I would like to use OOP. Some of these reasons may already be satisfied by PB and some people have pointed out that PB does support some OOP paradigms.

I would like to have functions that return multiple values. If I want to show a photo on a web page, I want to know if the photo folder exists, if the photo exists, if the photo is portrait or landscape and if a thumbnail of the photo exists. The web page will report one of the following:(folder missing – folder name), (photo missing – photo name), or (show the photo with correct height and width). Usually I have a success flag as well, for cases where the input data was rubbish and no result could be returned.

Functions generally return only one value which makes handling tasks like the one above difficult. I can return an array from a function, but splitting up the items is messy. I can also use several simple functions that each return one value, but then I have to write more code in the calling procedure, when what I want to do is push these details to a lower level.

Is there any reason why a the return value from a function in a procedural language can't have several parameters just as the call to a function can have several parameters? If this was the case, then one of the attractions of OOP would be reduced.

Ms-access has controls which are objects, which means that when I do something with a control, several items of information are automatically generated. If I select a value in a list, the selection items ID is recorded and if the list is a data bound list, the dirty property is set indicating that the record has been edited. I wonder how I can deal with similar situations in PB, where one simple user action triggers several concurrent changes that each need to be handled. The fact that ms-access has controls that are objects means that the developer does not have to worry about managing lots of the low level detail, which are represented by control properties in ms-access. Unbound forms can also be used in ms-access but they take a lot of coding to create. I think that forms in PB would be similar to unbound forms in ms-access. In summary OOP seems to allow for objects to coordinate with each other automatically in certain cases such as with data-aware controls and this takes some of the burden off the developer. I don't know the answer to this, I just hope that there is elegant solution out there that has not been found yet.

I would like controls to be objects even if the language is not OO so that they can automate some of the fiddly stuff and keep it behind the scenes.

I can't remember my user defined function names as my projects get larger. The self documenting capability of OOP becomes really important to not creating duplicate code. PB's modules may achieve something similar. I understand that functions defined in a file are added to the intellisense list in the IDE in PB (they are not in ms-access).

I welcome any contribution from anyone who can tell me more about the pro's and con's of PP and OP in a construction conceptual way that relates to how things can and cannot be done in PB. The outcome for me is that PB will probably be a learning environment where I develop the conceptual frameworks that allow me to advance in other languages and environments. PB has greatly lowered the barrier to learning application design for me and this is what its purpose is. I would be happy to write apps in PB but I need to know how to deal with complex items like photos or database records that have lots of properties before I do so.

[skywalk]

You are mixing terms OOP and COM. You seem to be asking if PB can use pre-compiled COM objects? Yes, but with the COMate library or similar PB code.

As to when or if one needs OOP, that is a long discussion.

[IdeasVacuum]

Functions generally return only one value which makes handling tasks like the one above difficult.

Erm no, you can return as many individual values as you wish via pointers. You can also have many values exchanged via a structured value.
So this is not true, a Procedure can return mulitple values:

Is there any reason why a the return value from a function in a procedural language can't have several parameters just as the call to a function can have several parameters? If this was the case, then one of the attractions of OOP would be reduced.

[IdeasVacuum]

I can't remember my user defined function names as my projects get larger.

That would be a problem in almost any type of language - sounds like you are as old as me . PB provides a lot of help in the IDE, and indeed you can Declare all of your app's functions in one list, which would help.

[IdeasVacuum]

I would be happy to write apps in PB but I need to know how to deal with complex items like photos or database records that have lots of properties before I do so.

Using Structures is very easy and very powerful: http://www.purebasic.com/documentation/ ... tures.html

[Thorium]

I would appreciate it if some people would point out specific examples in PB where they get stuck without OOP.

You never get stuck because you dont use OOP.

OOP isnt a functionality, it's a programming style. It does not add any possibilities to the language. In some scenarios it might be better to use OOP style but it's never necessary. It's not even about the language, you can even programm assembler in OOP style. OOP languages just assist you in programming in that style and make it easier for you.

The only times you realy need OOP to some extent is if you interface with OOP code like COM.

[BorisTheOld]

OOP isnt a functionality, it's a programming style. It does not add any possibilities to the language. In some scenarios it might be better to use OOP style but it's never necessary. It's not even about the language, you can even programm assembler in OOP style. OOP languages just assist you in programming in that style and make it easier for you.

Beautifully put, Thorium.

@AndrewM

Over the years, I've found that structure is the key to successful programming. And it doesn't really matter if one implements it with modules or classes, the objective is the same. Code should be written in functional units that can be easily maintained, have limited public interfaces, and can be used by many applications.

I've been programming for 50 years, and in the past I've always used modules, with externally defined structures representing each instance of a module. However, with PB, I decided to take it one step further and "simulate" OOP using the Interface feature, some macros, and hand coded virtual tables. Each instance of a class is now just a pointer to some dynamically assigned memory. I made this choice because PB didn't have a module feature when I first started using it.

But it doesn't matter what technique I use, the inner workings of my modules and classes are exactly the same. The code is identical -- it's just the overall application structure which is a little different.

So don't get hung up on OOP. As Thorium said, it's just a style.

[USCode]

Ms-access has controls which are objects, which means that when I do something with a control, several items of information are automatically generated. If I select a value in a list, the selection items ID is recorded and if the list is a data bound list, the dirty property is set indicating that the record has been edited. I wonder how I can deal with similar situations in PB, where one simple user action triggers several concurrent changes that each need to be handled. The fact that ms-access has controls that are objects means that the developer does not have to worry about managing lots of the low level detail, which are represented by control properties in ms-access. Unbound forms can also be used in ms-access but they take a lot of coding to create. I think that forms in PB would be similar to unbound forms in ms-access. In summary OOP seems to allow for objects to coordinate with each other automatically in certain cases such as with data-aware controls and this takes some of the burden off the developer. I don't know the answer to this, I just hope that there is elegant solution out there that has not been found yet.

I would like controls to be objects even if the language is not OO so that they can automate some of the fiddly stuff and keep it behind the scenes.

Technically PB does have objects: http://purebasic.com/documentation/refe ... jects.html
Instead of this syntax: Object.Method(parameters...)
You do this in PB: Function(#Object, parameters...)

For example, when an item is selected in a TreeGadget, you simply call GetGadgetState(#Object) and it returns which item is selected.

Personally, I like the control/flexibility PB gives me vs. data-bound/aware objects and find it doesn't really require much more work.
For example, to mark a selection as "dirty", in response to an event you could just set a value/boolean using SetGadgetItemData(#Object, ...) and retrieve that GetGadgetItemData(#Object, ...).
You bind an event to a gadget using BindGadgetEvent(#Object, ...).

[AndrewM]

To Everyone, I find the above information very valuable. I think in most subjects, it is the intermediate level that is the hardest. The basics are usually well documented and by the time you are advanced, you have a feel for the subject so can fill in the gaps. Looking at the posts above, I can see three authors who have discovered ways of doing things for themselves by creating frameworks that they have developed for managing complex projects. My own efforts have reached the point where I am dealing with applications that have upwards of 200 objects (forms, tables, views, modules etc) and I need to develop better skills for organising projects.

Discovering structures is the best thing so far. Declaring functions adds them to the intellisence list? I only know declaring functions to allow their names to be used before they are defined.

The confusion about OOP and COM comes from previous discussions on OOP in this forum. I am assuming that PB is a wrapper for windows controls such as listboxes and checkboxes and as such if these are objects, then although PB is a procedural language, it may be able to get and set properties of these objects and maybe even call their methods. Several previous posts allude to form controls being objects but give not a clue on how this could be used (or not used). I think in most cases, people are looking for an entry point into a subject so that they and do more research and I certainly need that in this instance.

Regarding OOP and procedural languages being of equal power, I have been thinking of this. The only advantages of OOP that I can come up with that apply to my projects are that:

• many objects are part of collections and you can cycle through the collections quite easily (e.g. can close all open forms);
• With datasets, there are a set of methods for finding stuff;
• Complex procedures often have a long call stack that may visit a particular bit of data many times and if one of the nested procedures could change a value used by the calling procedure (e.g a working directory). OOP may be less vulnerable to this as it makes less use of global variables; and
• Automatic clean up on completion.

I have gotten along in procedural programming so far but as a I have heard, it takes a long time to start writing code that doesn't suck. Has anyone published a formal discourse on procedural vs OOP? That is not championing OOP, it is just figuring out where the boundaries are. Perhaps some vb.net programmers would like to use PB but would like to see that it can do what .net does even though it is procedural.

From a search on this subject I found this

There are few people who actually know what "object-oriented" means, even if they are the fiercest evangelists of it.

[IdeasVacuum]

e.g. can close all open forms

CloseWindow(#PB_All)

makes less use of global variables

Entirely programming style - use as you wish in PB

Automatic clean up on completion

Automatic in PB, though you can Free just about anything, anytime

[AndrewM]

I have done a bit of research and the wider internet confirms most of the statements made in this forum regarding the merits of OOP. The consensus if I can call it that is that OOP is good for:

• Work with data;
• Graphical user interfaces; and
• Large systems with tens of thousands of lines of code.

That is pretty much the way ms-access is set up, so that maybe the big M$ knows something. Procedural code in ms-access is used in programming by most users. This outcome is good for me as it provides me with ammo to defend my coding style from snobs who use C# or something. Dealing with recordsets without a data access object in PB still worries me so I have yet to try any serious applications.

Procedural programming also has its defenders, some who thing that OOP is the wrong tool for many jobs. The core of this argument is that forcing everything into classes can be clumsy. I suspect that in may cases, good classes can be hard to define for abstract subjects.

Another thing that came up was a statement that simply putting code in class modules does not equal object oriented code. Procedural code in class modules is procedural coding. Unless the code in the class modules is created in a way that creates encapsulation it is not OOP. The decoupling of getting and setting of properties is one of the crucial dividing line between PP and OOP. There is other stuff, and I will have to read it again.

Cheers Andrew

[PB]

> I would like to have functions that return multiple values

Global variables, which set their values in the function. Done.

[IdeasVacuum]

At the end of the day, it is mostly about programming style and how you layout/organise your code.

Large systems with tens of thousands of lines of code.

Essentially, OOP was developed to make code more robust. Robustness however only comes with good design and diligent coding, no matter what language, method or style. You can get that right, or terribly wrong, using any programming method. In my experience on larger projects, OOP becomes an ocean, difficult to sail.

[BorisTheOld]

The decoupling of getting and setting of properties is one of the crucial dividing line between PP and OOP.

Not strictly true. Non-OOP code can be structured to encapsulate data.

Our largest application has about 800K lines of code, and handles about 3000 GUI items. Currently, it's written in non-OOP PowerBasic code consisting of about 200 DLL modules. There are no global variables, and module properties are accessed via public Get and Set procedures. GUI items exist as instances of structures, which are passed to appropriate DLLs for processing.

We're currently converting this code to PureBasic using an OOP style. The only difference from the PowerBasic code is that data structures are defined within the class, and class methods are used to allocate and initialize an instance of the structure. Otherwise, the code is functionally identical.

Here's a link to a posting I made about a month ago. It shows how we structure our code to use an OOP style. A non-OOP version of this would look almost the same. It's interesting to note that if the code is modified slightly to eliminate the use of the PB Interface feature, it would still function in an OOP style, but would be pure procedural code.

http://www.purebasic.fr/english/viewtop ... 40&t=57143

[AndrewM]

Here is a long discourse on the subject of OOP vs PP. It is interesting how much philosophy and individual differences between people determine which tools they use.

http://www.linuxjournal.com/content/pro ... ural-vs-oo

@BorisTheOld. What exactly does the example code in your recent post do?