|One of the problems for people to to PowerBuilder is where it place a
function. There are many choices, in an ancestor object, global function, non visual
object, non visual object with autoinstantiate set. The answer depends of a variety of
Firstly lets narrow the options and remove the global function from the picture. Many OO
purists would cringe at the thought of anything global but I would not discount anything
just because it was not pure, however there are many other reasons for not using global
functions. Firstly they are handled differently by the PowerBuilder environment in that
you do not decide the life of a global function, each time you use it, it gets loaded in
from the PBL, basically a create and destroy. Also a large function is not always loaded
completely into memory so you may get multiple hits to disk. Then there is function
overloading which is a great aid to development which you cannot use with global
functions. All these reason are why you should not use global functions in your
Next is ancestor functions. The benefit of ancestor functions is that you can code tighter
functions using the this operator, the functions are always available and they are loaded
into memory as soon as the object is created. This is also their problem, if you have 100
functions and I only want to use 10 then I have 90 functions in memory that I don't want.
Ancestor functions also tend to lead to sloppy spaghetti code with multiple nesting of IF
statements and flags all over the place. So the golden rule is where possible do not put
functions in your ancestor objects. Sometimes its unavoidable to put functions in your
ancestors, for example the code to interface into a service architecture must be in the
ancestors. If you must do so then make sure they follow the 90% rule. The 90% rule say
that 90% of the uses of the object in our application must make use of the function
otherwise its overhead and should not be there.
Non Visual Objects
Lastly we have the two types of non visual object, with and without the
autoinstantiate attribute set. The best use of these two types depends on how you want to
use the object and related functions. If you want to build a service object that will be
used in a service architecture then you are better off with a regular non visual object
without autoinstantiate. The main reason being that you cannot pass an autoinstantiate
object by reference. Also you are not likely to need the primary advantage of the
autoinstantiate type which is the automatic creation of the object on use.
Autoinstantiate objects are quicker to create and destroy and they also have another
advantage in that they are only created when they are used. With normal NVO's you have to
figure out when to create the objects, if you have complex logic with many calls to
functions in the object then you would probably just create the object at the top of your
script even if the flow of logic never used the object. In PB5 if you have multiple exits
to the function you also need to worry about destroying the object in multiple locations.
you do not have to worry about these things for autoinstantiate objects. In tests I found
the same function in an autoinstantiate object was quicker to call than to create the
equivalent NVO and call the same function.
To summaries, never use global functions, use autoinstantiate non visual objects for
grouping related functions such as string manipulation or Word integration, use regular
non visual objects for service objects which you need to pass by reference.