RE: Object overloading (data)

It already is, there are eight procedures for address resolution, the
problem is that everyone and their brother tie them together in slightly
different, inconsistant, and mostly incorrect ways. We have to have a
central, single interface to protect the stupid users from the stupid
developers, this also gives us the "tying" logic in one place, not in x
number of web/native applications.

Duane Christen



 

-----Original Message-----
From: java400-l-bounces+dchristen=mcleodusa.com@xxxxxxxxxxxx
[mailto:java400-l-bounces+dchristen=mcleodusa.com@xxxxxxxxxxxx]On Behalf
Of Larry Gorlin
Sent: Wednesday, March 29, 2006 12:41 PM
To: Java Programming on and around the iSeries / AS400
Subject: RE: Object overloading (data)


I vote that you're trying to do too much with one call.  Break it up
into multiple procedures, one for Zip code resolution and another for
address resolution, and make the API as simple as you can.  


-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Christen, Duane J.
Sent: Wednesday, March 29, 2006 9:19 AM
To: 'java400-l@xxxxxxxxxxxx'
Subject: Object overloading (data)

In building an API on the i5 with RPGIV which is intended to be callable
from native and web applications I have come across a possible problem
that I have not encountered before. 
 
The API is used to select from a list of addresses, for a customer
location, from a USPS City/State/Zip table and a USPS Street address
table, scored by how well the address matches the user provided
information. Depending on the user provided information the city state
zip lookup may result in more than
1 match, e.g.. If the user only provides the city and state and that
city has more than one zip code the API needs to return the list (data
structure/object) to the caller which will display the list to the user
who will select the appropriate zip code and call the API again with the
additional information (zip code). The API will then find a single match
in the USPS City/State/Zip table and continue on to lookup the street
address from the user provided information, and return a list of matches
to the caller.
 
In RPGIV I am overloading the data structure by using the first 10 bytes
of the structure to "name" the format and using the larger of the two
structures as the procedure return variable definition. The calling code
looks a the first 10 bytes and determines if the API is returning the
City/State/Zip structure or the Address structure and does the
appropriate processing.
 
Now, finally, to my question. If the caller is a Java method can it
determine, using the first 10 bytes, if the object/structure returned to
it is a City/State/Zip or Address object?
 
Is there a better way to handle structure/object return value
overloading for RPGIV/Java?
 
Thanks
Duane Christen



NOTICE: This electronic mail transmission may contain confidential
information and is intended only for the person(s) named.  Any use,
copying or disclosure by any other person is strictly prohibited. If you
have received this transmission in error, please notify the sender via
e-mail.



--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/java400-l.

________________________________________________________
        - ISLAND PACIFIC E-MAIL LEGAL DISCLAIMER -

  This email is covered by the disclaimer linked below.
          You are urged to read the disclaimer.
        <http://www.islandpacific.com/email.htm>
_________________________________________________________