Scott
Both you HTTPAPI and CGIDEV2 has becommed a part of RPGLE, what is the
difference to define a "special file" (in a special payable product) and
include a HTTPAPI/CGIDEV2 "handler" - none !!!
I totally agree tha OA isn't what it claims to be - in fact it once again
brings us years back by promissing RPGLE people that a graphical UI can be
acheived with 600$ on a P05
/henrik
Scott Klement <web400@xxxxxxxxxxxxxxxx>
Sent by: web400-bounces@xxxxxxxxxxxx
20-04-2010 21:03
Please respond to
Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
To
Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
cc
Subject
Re: [WEB400] Why use PHP? What are the disadvantages?
On 4/19/2010 6:31 PM, Jon Paris wrote:
For one either typeless parameters or overloading (or both if I'm
greedy!)
One things I've learned from the constant "RPG should be OO"
conversations on Midrange.com is that when you dig deeper, you find out
that most people don't really want OO. They want some feature that an
OO language they've used (such as Java) happened to have. And it really
had nothing to do with OO, it was just something that the language
happened to have.
You ask for overloading and typeless parameters...
Overloading is a common thing in OO programming -- you *might* even say
that if RPG was OO, it'd have overloading. (But that'd be a stretch,
since it could certainly be made OO without overloading. Still,
virtually every OO language has overloading, so maybe you could expect
that.)
But "typeless" (or "variant") parameters are not a common feature of OO
languages at all.
My opinion: I'd rather have "typeless" parameters than overloading.
That would be far more useful, IMHO...
Even better would be "sizeless" variables/parameters. I can achieve
something similar to typelessness by defining my parameters as
character, and simply using BIFs to convert it on the fly. But
sizeless? Very hard to work around that.
By sizeless, I mean that you don't have to define the length of a
variable at compile-time. The system manages the memory for the
variable under the cover, starting with a small amount of memory, and
automatically expanding it as necessary.
Right now I spend a lot of time mucking about with how to efficiently
pass parameters and return values with VARYING, *VARSIZE, and CONST to
enable some level of size-independence. And I find myself spending a
fair amount of time figuring out "maximum possible sizes" or writing
both "long and short" versions of procedures to help cope with the
performance issues of long parameters. IBM must've seen this too, based
on the new RTNPARM keyword.
But eliminating the need to know the size of strings or arrays at
compile-time would certainly make my life easier.
For two - the first is no help unless you also get this - and this is
the hard one. PCML needs to be updated to support all datatypes and so
do operational descriptors.
PCML doesn't even need to exist, IMHO. It's an overblown,
overengineered, overcomplicated way to do things. Simple embedded
signatures would be much more efficient than kludgy, limited, XML
documents.
Embed a binary (machine-readable) version of the PI's into the *MODULE
object, and carry it forward to the *PGM and *SRVPGM objects. Callers
shouldn't have to re-define the prototype, the compiler should be able
to read it efficiently from the object.
If you need PCML for slow, cumbersome languages like Java, then have it
convert the binary object to PCML on-the-fly... it shouldn't be that hard.
But having the compiler parse XML for every thing I call would really
slow things down, and what advantage would it offer?
I know XML was very much a buzz-word a few years ago. But haven't we
yet learned that it's not the answer to all problems?
Open Access shows that Rochester are at long last prepared to think
about supporting RPG oriented initiatives BUT Rational have also
demonstrated with OA that they expect to get $s for their efforts. So
something like OO features for RPG that have little user demand and
would cost substantial amounts don't seem to fit a model where there
needs to be revenue associated with any new feature.
Open Access gives us very little we didn't have before. It, at best, is
a stepping stone to a better solution down the road. And a tool to make
it easier for vendors to write their screen scrapers.
I certainly understand and agree with the value of being able to
separate the business logic from the display logic, print logic, and
database logic. I certainly understand and agree that it's valuable to
separate them and be able to plug in new back-ends as desired.
However, what it doesn't give us is encapsulation. Doing things
properly, the caller shouldn't know or care how the UI works.
Unfortunately, Open Access doesn't give us that. From the callers
perspective, the UI *must* work exactly like a display file. It must
have DDS source, all the proper indicators, etc. Under the covers,
the handler is taking that "display file data" and converting it to
something else -- the prgoram is designed for a display file, and the
handler is "tricking it" by outputting another way.
In other words... it's a screen scraper. It's a temporary stop-gap
solution to help us make progress until we rewrite our programs to use
the proper paradigm. At least, it *can* be a stop-gap solution like that
-- provided we pay for it, and we also pay for a 3rd party handler. By
itself, open access doesn't even give us THAT much.
If you think open access gives RPG a future -- I'd say you're high. It
pushes RPG more and more into the ranks of being a legacy language. And
it provides once and for all that IBM doesn't care about RPG enough to
give us a real solution.
A real solution will be event-driven. When a user clicks a button, or
makes a selection, etc, etc, it will hook into our code. In a
client-server GUI application, this is the normal way. Ever written a
program in Visual Basic? Visual C++? This is what happens... You have
a drag & drop interface where you drag buttons, list boxes, text boxes,
and other widgets to create a nice GUI panel. At run time, when a user
clicks a button, it calls a "subprocedure" with information about what
was clicked. In the newer, web wway of doing things it pretty much
results in the same thing, except that you use AJAX with a framework or
two. After the plumbing, though, it amounts in the same thing. You
click a button, it runs a procedure in a program on the server that does
some processing that comes back and affects the output. There's really
no way to incorporate this model in the RPG Open Access approach
directly. (Though, you could do this through subprocedure calls without
OA)
Open Access does have it's uses. Sometimes I think I'm getting too
negative about it. There are places where it's very useful. But, as
far as modernizing the user interface, it's really just a stop-gap
measure.
But the fact that IBM is charging extra for it, and even with that
extra, you aren't getting a solution, just plumbing that can be used for
a 3rd-party vendor to provide a solution... I just don't see this
getting very high adoption.
And without high adoption... without it being a core part of the
language... without those things it really doesn't solve the problems.
We already have lots of ways to bring RPG code to the web. What we
don't have is a single, common, regular interface that everyone uses
across the board that's "part of" RPG. And Open Access is making
absolutely NO effort to provide this.
Sorry, I've gotten way off topic. :)
midrange.com
