× 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.


  1.  Home
  2. RPG400-L
  3. January 2010

RE: RPGV?



Granted, actual "classes" won't exist in the language, and you won't get
inheritance.

Also, "classes" and "inheritance" also have nothing (well ok, someting ut not essential) to do with OO.
Just concepts implemented in many OO languages.

Javascript i.e. is fully OO, but has no classes and (therefore) no inheritance.

Yes, i'm in a pedantic mood today

To: rpg400-l@xxxxxxxxxxxx
CC: rpg400-l@xxxxxxxxxxxx; rpg400-l-bounces@xxxxxxxxxxxx
Subject: RE: RPGV?
From: BMartin@xxxxxxxxxxxx
Date: Tue, 12 Jan 2010 09:51:35 -0500

But Namespaces are indeed an OO concept. That is what you encapsulate
your Classes in. In java this is known as a Package. By introducing
namespaces you begin to flirt with the idea of offering more and more OO
features into the language. You can simulate a class using a data
structures and procedures. Offer overloading of procedure names and this
really starts to take some shape.

Granted, actual "classes" won't exist in the language, and you won't get
inheritance. But if you offered Interfaces as someone else suggested its
just another piece of the OO pie.


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



john e <jacobus1968@xxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
01/12/2010 09:12 AM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: RPGV?







Namespaces / overloading has nothing to do with OO.
OO is all about encapsulation.
You don't encapsulate anything with namespaces/overloading.

OORPG... please

First try to make the current version of RPG a bit more sane...

And why bother, i never encountered an RPG programmer who even heard about
terms like "encapsulation" or even "variable scoping", let alone use it.



To: rpg400-l@xxxxxxxxxxxx
Subject: Re: RPGV?
From: BMartin@xxxxxxxxxxxx
Date: Tue, 12 Jan 2010 08:40:59 -0500

So you want RPG to go OO?

This is essentially what you'll get if you allow procedure overloading
and
namespaces. At least you'll have almost all the language construct to
make it happen. Coming from C/C++ in all my time in highschool and
college and then learning Java as well I'm quite fond of OO and really
miss it, so it wouldn't be so bad for me :D

I'm just wondering how the RPG lifers feel about this. Without a
background in an OO language I would think many RPGers would be a bit
lost
with Namespaces and Procedure overloading... just as most have bucked
the
idea of Modules/Service Progams. I'm not saying it shouldn't be done. I

very much support it, but I just hope everyone realizes that it'll be
another one of those 30% adoption situations again (or whatever the case

is for service programs).


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



Larry Ducie <larry_ducie@xxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
01/12/2010 06:34 AM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>


To
RPG400 <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: RPGV?







Hi Hans,

My two cents on this:

The DCL keyword: This would make my RPG look like CL. That alone would
kill it for me.
Comma vs Colon: Only a proctologist would really care.
Calc Spec V: Already free so we just lose the /free and /end-free and
make
it compulsory.

At this point in time I really don't think I would want my $100 spent on

freeing RPG. It is functionality I want, not lipstick.

I would spend my money on:

1) Overloading sub-procedures ($75)
This is an obvious need and is well overdue.

2) Namespaces for Service Programs and Modules ($20)
I would like to have a NAMESPACE keyword (H-spec) for a SRVPGM or MODULE

and then qualify a procedure with that namespace. This would allow me to

reference two service programs that export a similarly named
subprocedure
and not have conflicts.

For example, two SRVPGMS export a getName procedure. This conflict is
solved with the following two lines:
NAMESPACE(MYSRVPGM1 : 'Contact')
NAMESPACE(MYSRVPGM2 : 'Customer')

I could then have:

contactName = Contact::GetName(parm);
customerName = Customer::GetName(parm);


We REALLY need this. We use so many SRVPGMS and it just gets harder and
harder to keep procedure names unique across our SRVPGMs. We simply
shouldn't have to.

3) Ability to put a Binding Directory into another Binding Directory
($5)
We have lots of Service Programs, and we generate quite complex
inter-dependencies. For our prototype copybooks we can copy our
prototypes
into other copybooks to form new (more complex) copybooks.
Unfortunately,
we can't do the same with our Binding Directories. This is a real pain.

Example:
A Person 'object' is implemented in three SRVPGMS. Each has its own
copybook and Binding Direcory. To include the Person objects in a
program
we use a /include of the PERSON copybook (which includes a /include of
the
three SRVPGM copybooks). We also reference the PERSON Binding Directory.

This doesn't reference the theee original Binding Directories (because
it
can't) so it has to list the three SRVPGM objects again. If we split one

of the original SRVPGMS into two we would have issues. The copybook is
easy because we reference the two new copybooks in the original and all
copybooks built on it would get the new values. However, ALL of the
Binding Directories that list the original SRVPGM have to be found and
amended. This could be solved by simply amending the original Binding
Directory to include a refenrece to the two new Binding Directories and
letting all references filter through. Just want to keep it consistent.

Hope that all makes sense, and Happy New Year!

Cheers

Larry Ducie



_________________________________________________________________
View photos of singles in your area! Browse profiles for FREE
http://clk.atdmt.com/NMN/go/150855801/direct/01/
--
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.



--- This message (including any attachments) is intended only for the
use of the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential, and
exempt from disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any use, dissemination,
distribution, or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify us and
destroy this message immediately. ---
--
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.


_________________________________________________________________
Download gratis emoticons voor Messenger
http://www.rulive.nl/aspx/emoticons.aspx
--
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.



--- This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us and destroy this message immediately. ---
--
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.


_________________________________________________________________
Het laatste nieuws, shownieuws en voetbalnieuws op MSN.nl
http://nl.msn.com/

As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
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.