Re: Compiling after file changes

Comments inline

On Fri, May 28, 2010 at 7:14 AM, David FOXWELL <David.FOXWELL@xxxxxxxxx> wrote:

-----Message d'origine-----
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Simon Coulter


Well accepted standard in the OO world. Common as mud and
makes a lot of sense. Tell your management weenies that I
said they were a bunch of numptys and it's time they got with
the program.

My French won't go that far - a quick google translate :
Dites à votre saucisse de gestion que j'ai dit qu'ils étaient un groupe de numptys et il est temps qu'ils obtenu avec le programme.

"Management sausage" doesn't seem right somehow. Are they confusing Australian weenies with an American
synonyme?

weenie - Slang A person, especially a man, who is regarded as being
weak and ineffectual.

So, if a file had 100 fields, you'd probably just do getters for the ones you need and let the next person add a getter when it was needed? Management doesn't see the advantage of the getters for each zone and I'm trying to think of the reason.

DO NOT SIMPLY CREATE GETTERS/SETTERS FOR EVERY FIELD!

Instead, have business logic routines that you can call.

Do this:

if CUSTOMER_IsOverCreditLimit(wCustomerNumber:wSaleAmount);
//display message?
endif;

Instead of this:
if wSaleAmount > CUSTOMER_GetCreditLimit(wCustomerNumber);
//display message?
endif;


Here's a true story...at a prior place of employment we had a (Item
Master?) file with a active/inactive (?) flag field in it.
All over the place you'd see code like so:
chain itemNbr ITEMMSTR;
if actFlag = 'A';
// do something with active item
else;
// do something else
endif;

Then the business decided that checking the flag by itself wasn't
enough, we also had to consider condition X.
The business was shocked to find out what it was goingto take to make
that simple, to them, change. In fact, I think we ended up abandoning
the change.


You'd still going to need some getters, mainly for data that is to be
displayed or printed
CUSTOMER_GetName();
CUSTOMER_GetMailingAddress(cCUST_ADDR_0100:wCustomerAddressDS);

Also consider procedures such as
CUSTOMER_OpenBasicList();
CUSTOMER_RetrieveBasicList(wCustomerBasicInfoArray
: %dim(wCustomerBasicInfoArray));

Which you can use to populate subfiles or web UIs.

Yes, but you resolve that by including a level request as
part of the I/O interface so programs requesting level 1 get
a data structure that is how the record looks today, those
requesting tomorrow's level 2 will get a different structure
with new fields added (or old ones removed, or both), and so on.

Now even I am shocked. So the DS's would be hard coded? The procedure in the i/o module could not read directly into > the DS. That and a level request seems to be a lot of unnecessary complexity to me.

Yes, but don't think of them as hard coded. Instead, think of them as
never changing. Each version of a DS is defined once in a /COPY
file and if you need more fields, you add a new version.

When you add new functionality, nothing needs to be recompiled.
Unless an existing program needs to make use of the new functionality,
then you modify it to use the new version of the DS.

The IBM API's provide a good example of this method.



HTH,
Charles