The only thing I really miss in RPG that OO has is inheritance. It
would be nice to be able to extend a service program without having to
re-compile everything to use it.

Perhaps you're doing it wrong?

Service programs can easily be updated without having to recompile (or
rebind) anything that calls them.  This has been the case since ILE was
introduced.

I have been coding in ILE since 1995, and have never (well.. almost
never) needed to recompile something that calls a service program unless
I wanted to add additional functionality...

In 1995 I was still in high school, so I haven't been doing it that
long :-). I probably am doing it wrong though. I just get nervous
about adding new procedures to service programs. I've been bitten
before by it, so I get a little gun shy.

I did recently read a presentation of yours about service programs. It
seems adding the new procedures after any current ones seems to be
what I would need to do.


I also agree that Open Access is going to give us very little. I think
it will help a bit, if I understand it correctly, with stuff like XML
parsers or something like that. I don't think it will be good for UI
at all. OO really is the best option for UI development, RPG is not,
IMHO.

I don't see how Open Access will help with XML parsers.  XML doesn't fit
the paradigm of a physical file, and therefore doesn't fit Open Access.

I shamefully admit I did not read much about Open Access, but I
thought it was to optionally replace the 5250 data stream.


I also don't think OO helps at all with UI development.  Visual Basic (I
don't mean the .NET version, I mean the VB3, VB4, VB5, VB6) wasn't an
OO-language, but yet worked brilliantly with UI development.  Likewise,
UI development in C using tools like Glade and GTK works brilliantly.
Even programming to the WIN32 API in C isn't too bad.

It needs to be event-driven, though.   OO languages can certainly
provide an "event listener object" with all of the routines needed to be
called in the case of events.  And that works.

But a data structure with all of the routines in an event works just as
well.  It doesn't need to be OO.  It doesn't need to support
polymorphism, inheritance, instantiation, et al, in order to work well
with a UI.

I have not done much UI. I wrote a simple browser in VB6 and I've done
some Java Swing (not of it pretty by any means). So I can't speak for
any C UI API's. It seemed to me that events would be better described
in an object, but that could just be my OO way of thinking.



The main issue I have with PHP is really it's a scripting language.
Not that scripting languages are bad, but I just like my end programs
compiled. (Quick Google search does show you can compile PHP, I was
unaware of that). So, this complaint is probably not valid and I
should read a little more before I complain :-).

So if you write the same code, and it runs the same way, with the same
performance, it's still better than it's compiled vs interpreted?

To me, compiling is just a way to improve performance by reducing the
CPU cycles required at run-time.  If it performs as well (or better) as
an interpreted language that it would as a compiled one, then there's no
value to compiling.

While tools like HipHop do improve the performance of PHP -- the
interpreted performance isn't bad either!  (Much better than compiled
Java in my tests!)  So why mess with it?  I won't optimize my code until
I find a performance problem with it.  And I'm not having performance
problems in PHP.

I guess it's just more so that a compiled version seems safer. Seems
like there would be less room for runtime errors. I see them all the
time in JavaScript.

--
James R. Perkins

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.