Re: Creating XML document via SQL - Db2 for i 7.2

Mike

RPG Service programs isn't object oriented because they are missing
important functionallity
that defines OOP.

An OOP class consists of properties and methods (a recipe) that can be
instantiated into
runable objects (instances) like ...

myObject1 = new nameClass('Henrik')
myObject2 = new nameClass('Mike')
myObject1.log() // the "log" method logs the objects name property value
"Henrik"
myObject2.log() // the "log" method logs the objects name property value
"Mike"

So the best way to describe a Service Program (as we know and use it in
RPG) is
that it is a program object without OOP capabilities.


On Sat, Mar 10, 2018 at 9:38 PM, Mike Jones <mike.jones.sysdev@xxxxxxxxx>
wrote:

Hi John,

I do think of object-builders as the same as object-users, since the
object-builders often use other people's objects. If they don't, they
probably should. Granted, the deeper you get into the objects, the more
details the developer is likely to have to deal with, and the less other
developer's objects are available to use.

Honestly, most OOP programmers don't know much at all about RPG or RPG
service programs, and most RPG programmers don't know much at all about
OOP. Hence, in most cases their opinions are uninformed ones.

I do consider service programs object oriented, but just not as flexible as
the capabilities of a language like Java or C#. Languages like Java and C#
allow the code to determine the executed code path much more at run-time,
versus the more compile time approach of RPG service programs. Shifting
more of the decision making that determines the code path executed to
run-time, enhances re-use, and allows one to create a smaller volume of
code.

Granted, I've seen some OOP code that I think is horrible. OOP is not a
magic bullet that prevents one from creating crappy code. I think the
opposite is true. OOP provides more flexibility, which allows one to screw
up even worse. On the other hand, I've seen some OOP code that is simple,
elegant, easily maintainable, and permits code re-use and flexibility well
above what is possible in RPG.

We could all go back to coding in Assembler, but our productivity would be
horrible. The evolution of software development is such that we should be
continuing to strive to accomplish more with less lines of code, thereby
evolving to code at a higher and higher level of abstraction. Both RPG
service programs and OOP exist for that same purpose.

SQL also allows us to accomplish more with less lines of code. I've taken
batch RPG programs that process data, measured in many thousands of lines
of code, and reduced them to a few hundred, dramatically reducing run-time,
and at least for me, dramatically improved read-ability, and the cost of
their maintenance. I provide high level SET based SQL statement(s), and the
SQL engine figures out the details. In practice, this is re-using IBM's
SQL engine objects, but not in the traditional sense of OOP or service
programs. The goals are the same though: code reuse, code reduction, and
providing solutions using a higher level of abstraction.

Small code volume and high levels of abstraction = higher productivity,
assuming the solutions are also read-able and maintainable.

Mike

On Fri, Mar 9, 2018 at 8:57 PM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Fri, Mar 9, 2018 at 9:49 PM, Mike Jones <mike.jones.sysdev@xxxxxxxxx>
wrote:

Embracing SQL is all about "delegating".

IMO, this is similar in concept to OO programming, where you rely more

on

others' objects, and have to let go of some of the details.

That's... an interesting opinion to have.

And you're certainly entitled to your opinions. But... the folks who
build the objects... do you not think of them as object-oriented
programmers?

Do you think of the object-builders as a different kind of programmer
than the object-users?

How about the folks who write ILE modules, programs, or service
programs which are then used by RPG programmers? There's delegation
going on there too, but RPG is certainly not very object-oriented, and
if you ask folks who use languages which are more widely recognized as
object-oriented, they would call neither the service-program writers
nor the service-program consumers "object-oriented programmers".

And by the way, I don't think likening SQL to OOP is a great way to
entice Jon. He's been known to have his differences with OOP as well.
;)

John Y.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD