function vs object

[JanyMoon]

I wonder is any benefit to use object with functions or just standard prg file with function?
for example:
i have 3 functions
a()
b()
c()

I can put this functions in one x.prg file and make
set procedure to x.prg
and then use this functions from application

or

make custom object and put this functions into object. Then
make
oFunc = createobject( "func" )

and then call functions like oFunc.a()

Have any idea about benefits of using object?
Thnks.

 

[craigsboyd]

With the examples given it is 6 of one and a half-dozen of the other. If however there were some start-up stuff you wanted to do before these functions were called or some shut-down clean-up type stuff you wanted to do then an object would provide you with a the ability to utilize the init and destroy events for this. Also, should you wish to have a much better handle on scope then the object could provide you a way to control this as well. Finally, if the three methods are related, an argument could be made that the object gives you a bit more organization and perhaps makes the code more understandable.

These are just a few of the benefits that an object can provide, but given the sparse amount of information you have provided regarding the functions it is pretty difficult to make a full determination of which might be better. Objects can provide a great deal of additional functionality, with very little overhead (depending on what kind of object you create of course). However, procedure files still have their place in certain instances.

SweetPotato Software Website
My Blog

 

[alvechurchdata]

However, procedure files still have their place in certain instances.

I still use procedure files for the very generic functions that get called time and time again.

At one time I did try to put everything into classes. All went well during normal operation but I found myself writing lots of code at start-up and shut-down to call a plain MessageBox if goMsg wasn't available and to use default English error messages if goData couldn't read the locale-specific messages.

I suspect that my mistake was that I went too far in my enthusiasm but I now use procedure files for this sort of thing and use class libraries for business and interface objects.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[GriffMG]

I'm a luddite and don't use classes at all - except for the inbuilt ones and the ones I've bought from West-Wind and the like.

I generally have one big procedure file which has loads of functions and procedures that I can call from anywhere in my system. It works very well for me and makes maintenance straightforward.

Martin



Regards

Griff
Keep [Smile]ing

 

[rkolva]

I use a good deal of both classes and functions in prgs and I would say it depends.

If I need some code generated quickly or I don't think I'll use it again then its going into a prg. Custom functions that are project specific definately go into prgs.

If it's something that I think I'll use again and again then the I'll spend the time and create a class. I may also put complex functionality into methods of a class and have a sort of 'wrapper' method that abstracts the entire process. I feel that makes the code easier to read as you can get the general idea of what's happening by looking at one concise block of code rather than scrolling through a thousand lines in a complex prg. For example: All my apps communicate data as XML using a class around WinHttp.dll. Since I use this many times it makes sense to build a class. This also gets a little complex as I check for which version of the DLL is on the machine, check connection state, trap errors, address proxy configurations, set time out thresholds, and the response from the server to decide if I need to cache the data and re-transmit later or go on my merry way. I could certainly do all that in a prg but I think it would be cumbersome to read. Since I also work with a team of programmers it makes it much easier for them to understand and maintain this code if its in a class.

Ralph Kolva

 

[TamarGranor]

One point I haven't seen here is that classes let you share data between functions. If there's state information you want to hold onto, for example, a class is the way to go.

Tamar

 

[TamarGranor]

One other point. Procedure files and classes are the only choices. I rarely use procedure files. If it's a separate program, it has its own PRG. Last time I tested, PRGs were faster than a procedure file containing the same code.

Tamar

 

[Dan Freeman]

The only place a class is a clear winner is those things you may want to eventually subclass. For instance, you might have a generic "msgbox" class that internally calls MessageBox(). Later you can subclass it to call a form of your own making and only need to change the name of the class getting instantiated in your code.

 

[Nifrabar]

Hi!
Maybe a bit off-topic but what's yr opinion using an app.object holding properties versus global vars in the start.prg?
To me there seems a parallel in th eoriginal topic <G>.
-Bart

 

[GriffMG]

Hi Bart,

Personally, I use globals and privates - locals only where required by third party stuff.

I use a simple naming convention - it's just a discipline thing really (IMHO). Same with oop (again IMHO) - it's just a technique for applying a discipline.

If you think about Dan's answer (two back) - no offence intended - what he says about classes can be done with functions just as easily.

I'm not so sue about Tamar's argument regarding speed though - if he's right then he has a point!

Anyway - the trick is to make what you write readable, and then keep it that way. It doesn't really matter if it's oop, or whatever the current flavour is, just keep it easy to read and it'll be easy to maintain.

If it really is difficult to understand, and I have some stuff that is, then it doesn't matter what approach you apply - it'll still take a bit of time to pick it up in a years time and modify it.

B-)

Regards

Griff
Keep [Smile]ing

 

[alvechurchdata]

if he's right

She's usually right.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[GriffMG]

Oops - sorry no offence intended

B-)

Regards

Griff
Keep [Smile]ing

 

[TamarGranor]

I prefer an application object for a variety of reasons, including the availability of IntelliSense, but also because it lets me keep everything together. My application object also includes code that populates some of those properties and other methods that apply to the application as a whole. (For example, on a project I'm working on, there's a method that logs activity.)

Tamar

 

[Olaf Doschke]

Hi JanyMoon,

additional to anything already said one difference from functions vs. an object containing functions is, that an object can be added to an object hierarchy via .AddObject() or .NewObject() method and therefore a method can reference it's Parent object via THIS.Parent.

On the other side you can always pass object references to a function within a PRG or a PRG by a parameter.

So I'd decide by the context, in which I'd like the functions and by inheritance needs, if implementing this as a class or procedural. Eg Math or Date/Time functions can be used in a more natural way if implemented as functions.

If a function handles things related to forms or a special control, it's better to have it as a class, that can be instanciated as subobject of a form or control instance. So you can have multiple instances each having some properties set differently for that special form or control. A thing you can't do with a set of functions/procedures, as they can't have properties/states.

Another thing is datasessions. A class (besides the session class, which is it's own session) is instanciated in the current datasession. So it can naturally access data/aliases/workareas in this session. If calling a method of an object you automatically switch to the objects session. That can be overcome by passing SET("Datasession") to the object and switching to the given datasession with SET DATASESSION TO within the object. A function does not need this, as it always works in the current datasession.
This can of course be advantage or disadvantage.

Bye, Olaf.

 

[justamistere]

I liked Olafs points. In addition I have done the following, a combination of both, as the requirememts molded it.

I created a .vcx ColorMessagebox class. Then I put the calling Function in my Procedure library of functions. This wrapper function, creates the object if needed, validates and displays syntax example. Then it passes the parameters on to the object, adding default ones and formatting some as needed. By preformatting the params, the object can be called with different params to make it's syntax more versatile. For instance word-wrapping can be automatic by nWrapWidth or break at the CHR(13)'s embedded. Or choose a preformatted generic msg by a "name".