× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



The point:

How many places may you end up calling ClientValidateName()?

Now what happens if you need to change how you do the validation?
With Simon's proposal, if you're change how you do all name
validation, you only have to change validateName(). If you're only
changing how clients are handled, you only need to change
ClientValidateName().

Let me tell you a true story, I worked at a company that had legacy
RPGIII and RPGIV programs. One of the files included and
Active/Inactive flag field. So as you'd expect in that environment,
there where plenty of places that checked IF IRSTAT = 'A'. Then we
got a change request, instead of just looking at the just flag, we
needed to take some other criteria into account. You can imagine how
much easier the change would have been if instead of IF IRSTAT = 'A',
the code was if ITEM_isActive(); Honestly, I don't think we ended up
making the change at all do to the effort required.

ILE programming is not easier, faster, or cheaper than RPG III.
Particularly when you first start (even for ILE experts).

Once you get some foundations built, the development will get easier,
faster, and cheaper, but still often not as easy, fast, or cheap as
whipping out an RPG III program; really that depends on how much code
reuse you get ie. are you doing something completely new or expanding
the existing functionality.

The ROI for ILE comes mostly from the maintainability. You'll find
all kinds of studies that show that the $$$ your organization spends
to initially develop an application are far, far outweighed by the $$$
you spend on maintaining it.

HTH,
Charles

On Thu, Jun 25, 2009 at 12:27 PM, David FOXWELL<David.FOXWELL@xxxxxxxxx> wrote:
-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Simon Coulter

New procedure: validateName( validateThis : withThat )
        This has the body of the code and performs the
validation giving a result that indicates whether validation
was successful (this could be simple TRUE/FALSE or a number
indicating the position of the first invalid character in
which case 0 would be all OK). This procedure MAY be exported
but I probably wouldn't do that. This will be a private
procedure used only within the module.

What if I want to do the same with my addresses which are treated in a separate module?


New procedure: validateClientName( name )
        calls validateName( name : CLIENT_CONSTANT )

New procedure: validateCompanyName( name : CLIENT_CONSTANT )
        calls validateName( name : CLIENT_CONSTANT )

I'd then have something like
New procedure: validateAddressStreet( street : ADDRESS_CONSTANT )
        calls validateAdress( Address : ADRESS_CONSTANT )

Wouldn't I end up with another function validateAddress identical to validateName? In fact, isn't validateName just encapsulating the %CHECK BIF?

Why not therefore, instead of

validatClientName ( name );  which is self documenting,

// Validate client's name.
%CHECK ( ClientName : CLIENT_NAME_CHARACTERS ); with a comment.

I hope I'm not missing the plot.
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.