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


  • Subject: Re: Scope of variables and subprocedures.
  • From: "Scott Klement" <infosys@xxxxxxxxxxxx>
  • Date: 13 Dec 1999 18:05:36 -0600

bmorris@ca.ibm.com wrote:
>
> In no particular order...
>
> Here are the things I think RPG IV needs to become a fully
> "grown-up" language:
> - scoped names within data structures so you can have subfield A in
>   two different data structures

This would also be on my wishlist.  Along with it, I'd like to see
something similar to the way structures work in C, where you declare
a "type" of structure, and then can declare many different instances
of that data structure.

Also, being able to treat multiple occurrance data structures more
like arrays would be much more useful than the silly OCCUR op-code,
(tho perhaps you already can, and I just havent run across it yet?)

> - unlimited-length character variables (or at least no arbitrary
>   RPG limit)

Hmmm.. this might be nice, but I'm not sure its necessary for
RPG to become a "grown up language".  Many languages have limitations
along these lines.  User spaces and/or dynamic memory allocation gives
us an easy workaround to this.

> - n-dimension arrays

I agree.

> - variable-type in prototyped parameters

I'm guessing that you mean "parameters of varying type", and arent
making some reference to types of variables... :-)   I also would
find that useful...  I can workaround this limitation by passing
a pointer instead of the variable type, of course, but this isn't
quite as slick.

> - bitwise operations for integer and character data

This has also been on my wishlist.  Things like XOR, AND, OR, and
bitwise shifting...  Being able to do this on integers would really
save me a lot of hassle...  converting to character, then doing each
byte individually is awkward.   And I have to use mult/div to do
shifting, which can't be efficient...

> - typed pointers with a dereference operator

On this, I'm going to disagree with you :)   I program in both RPG
(on the AS/400) and C (on Unix) and I think that the way pointers
work in RPG is actually much easier to deal with and support.
Things start to get very complicated, IMHO, when you start doing
typed pointers and deferencing...

I'd much rather make an integer BASED on a pointer, then reference
that integer (or whatever) than be able to use the pointer directly
with a dereference operator.  Granted, it may take a little more
code, but I think the code is much easier to use and maintain...

Perhaps you know of an advantage to derefencing that I'm not
considering?

>
> AS/400 related things that ILE RPG should have:
> - full null-value support
> - access to the IFS file system
> - library-qualified data-areas and variable-named data-areas
>
> Barbara Morris
>

How about native access to sockets, as long as you're doing IFS :)

and the ability to either use the select() API from sockets with
a display file, or the ability to wait on a data queue for socket
data would be nice.  (right now, its very difficult to multiplex
I/O between screen & sockets...  Writing a telnet type of application
in RPG would currently be difficult)

Its something that I wish for, anyway :)

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.