Question Persistent/Super Procedures

[TomBascom]

By the way -- in today's world (OE 10 and up) I would not waste any breath on persistent and/or super procedures. Especially not on crazy super procedure stack hierarchies -- that always was a train wreck waiting to happen and OO is so much better for the purpose.

 

[GregTomkins]

"Passing parameters to external procedures didn't become possible until version 5 (or maybe it was v6?) Without parameter passing you needed to use a mechanism like shared variables to pass information from one procedure to another. "

That's a fun fact that I didn't know! We started in v6, and I remember when internal procedures came out and it seemed like coding heaven. Good times.

 

[Rajat Sharma]

Hello everyone,

Thanks Tom, shared presentation was easy to understand and useful for me.

You mentioned in the presentation that “include files are worst practices talk for another time”. Could we replace include files with static classes, if yes then how because a class can contain data member and member functions not progress code that we use in include files?

Please suggest.

Thanks & Regards!
Rajat.

 

[TomBascom]

The mechanisms are obviously very different but the goal of reusing code is the same. Objects, be they static classes or more normal classes are clearly the more modern approach and have many, many advantages.

Include files are superficially attractive and easy to use but many of the things that make them "easy" are exactly the reasons why you should NOT be using them.

 

[tamhas]

Include files and static classes have absolutely nothing to do with one another. The reason for an include file ... except for a few people who just used them to break up a program into smaller units ... is because you have some code that needs to get used in multiple places. This can be variable definitions for *shudder* shared variables or it can be temp-table definitions used in multiple programs (not my favorite idea) or language extensions to package a little piece of code to compensate for something missing from ABL or just a common task or algorithm. What to do with these to avoid the include file depends on the use.

Shared variable definitions you can eliminate by refactoring the code to explicitly pass parameters, then you no longer need the shared variables and can eliminate the include. A common temp-table definition is eliminated by refactoring the code to put all references to the TT in one PP or class so the definition only needs to be in one place. A language extension remains one of the few arguments for an include ... but personally I tend to put such things in utility PPs or classes. Common tasks or algorithms you need to consider the type of need. In some cases putting them in a utility PP or class is the right idea. Sometimes it is refactoring the code so the algorithm is packaged in one place ... a good general design principle anyway.

Note that none of this has anything to do with static classes. Static anything is to be used with extreme caution because it is locked into memory until the session terminates. There are some less than amusing gotchas about doing database IO in a static. So, they should only be used for something that is always there by nature. E.g., in my developing MBD architecture I have a registry where subsystems register their availability so that other subsystems can find them without starting with a specific reference. This registry is intrinsic to the whole architecture and one can't do anything without it. Therefore, it works to make it a static.

 

[Rajat Sharma]

Thanks for replying Tom, Tamhas,

I think replacing shared variables with static class is a tremendous approach but if we face memory concern of static class (locked into memory until the session terminates) then is it worth to use a simple class and create new instances everywhere (I think this wouldn't work because every instance have its own copy ) or what should we do?

Should I use PP instead of include files?. Replacing include files with something is really confusing for me. If possible, could you please share any presentation or something that describe that how to replace include files with something and what are advantages of doing that.

Please suggest.

Thanks & Regards!
Rajat.

 

[TomBascom]

One nice thing about a static class is that there is only one copy.

True, once you create it you cannot get rid of it. But the same is true of a global shared variable so you have not actually lost anything.

You should not use include files in any new code. Full stop.

In the modern 4gl almost all situations where you might consider using a PP are better addressed by using objects.

 

[TomBascom]

There is no magic formula for translation from include file syntax to X.

To replace an include file you have to understand what it is doing. Then the appropriate replacement technology can be decided on.

Sometimes that might be an object, sometimes it might be a user defined function or an internal procedure. Other times it might be a dynamic query. The possibilities are nearly endless.

 

[rasool]

The mechanisms are obviously very different but the goal of reusing code is the same. Objects, be they static classes or more normal classes are clearly the more modern approach and have many, many advantages.

Include files are superficially attractive and easy to use but many of the things that make them "easy" are exactly the reasons why you should NOT be using them.

Hi Tom,
This is Rasool, i am new to PROGRESS. Recently i have gone through a code where both include files and procedures were used in the code. i am not able to get what is the difference between include files and procedures. can you please tell me the difference.


Thanks & Regards,
Rasool S.

 

[Rajat Sharma]

Hi Rasool,

Instead of writing same type of code again and again, we create an include file with different parameters and use it whenever we want to.

They are many types of procedures in progress like:

Internal, external, super, persistent..

You can go through progress handbook "Prohand" regarding the same.

Regards!
Rajat.

 

[rasool]

Hi Rasool,

Instead of writing same type of code again and again, we create an include file with different parameters and use it whenever we want to.

They are many types of procedures in progress like:

Internal, external, super, persistent..

You can go through progress handbook "Prohand" regarding the same.

Regards!
Rajat.

Hi Rajat,
Thanks for your update.
We can call .i files and .p files from different procedures(.p). My doubt is when exactly we use .p(called procedures) and when we use .i(include files), is there any advantage in using .i over .p or using .p over .i


Thanks & Regards
Rasool S.

 

[Rajat Sharma]

when we call .p program from another.p then ultimately we are switching control from calling procedure to called procedure. When control goes to called procedure then previous state of calling procedure is saved into stack memory.

we aren't calling include files, we are including the file (or including the code) in existing program.

making choice between include files or external procedures is depend on the business logic. But as Tom suggested in previous post that include files are very old and we have better options than using include files.

Regards!
Rajat.

 

[jdpjamesp]

One reasons that include files are bad is that the code contained in an include is included in each piece of code it is referenced in at compile time. As a result the rcode for your system is heavily bloated. If you call a persistent procedure, or use a class, then the code is only compiled once no matter how often you use it.

 

[TomBascom]

Aside from code bloat the major reason that include files are a bad idea is that they are poorly encapsulated. Code in an include can reference objects (buffers, variables, fields, frames, etc, etc...) anywhere in the including procedure. And the including procedure can do the same. This means that unexpected side-effects are a common problem and leads to serious maintenance troubles.

More modern structures, such as parameterized external procedures, internal procedures, user defined functions, super procedures and classes provide much stronger support for proper encapsulation and separation of concerns.