×
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.
<justin>
I'm not sure getters/setters and ORM are mutually exclusive. You use ORM to
set properties on your objects, but without getters/setters how do you
expose those properties? My thinking was to treat a *SRVPGM like that object
and access the "properties" via getters/setters.
</justin>
... setters and getters could handle complex (compound) types, (speaking in
OO Obejcts, speaking RPG DS) not only elementary types. The real thing is: a
type is a type and would not change is external content and behaviour -
never ever.
<justin>
Let me explain the issue I'm trying to solve so we're both on the same page.
Traditionally, RPG references a PF directly and is tied to the record format
at compile time. If an existing column was changed in the PF, all the RPG
programs that use it will fail with level check errors. This is rather than
having them run over bogus data. So the question is how to get the data
to/from that PF without tying every RPG program to a static format.
</justin>
... that's one of the limitations of RLA and why it should be changed to
SQL. Using SQL you would never (never ever!!!) reference a table in an
application, only use views and your external DS only adress views. As this
DS is a type, it would never change!!! If you need an extended database
object, you will get an extended view and an extended DS (OO names this
relation inheritance). Ýour existing getters and setters won't change - you
might have additional setters and getters, as RPG is rather limited and
doesn't know overloading, you would have to use some workarounds - some
naming conventions could help. All programms - not knowing additional
properties, would work unchanged, programms using it, you would have to
touch anyway and changig it to use the extended types.
D*B
As an Amazon Associate we earn from qualifying purchases.
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.