Re: 7.1 and RPG prototypes

Jon,

beeing part of the story has an advantage (knowing details) and might have a disadvantage ( beeing blind about some aspects...)

in one point, I would follow your arguments, without recompile of dependent objects, you would fallback to the situation we have today and even this would be effort.

But putting the Procedure interfaces to an associated space couldn't be a problem at all and deriving the prototype from the interface at binding time couldn't be a problem at all too and having this, the same checks could be done at binding time, that are done at compiletime now. There would be a gap: you don't have the source of the callee at bind time - maybe the point with most effort (I would have to think about this), but I'M very sure, that there would be a solution.

The point with enhancing signatures is not part of the originating discussion and compared to the originating discussion it is a nice to have. Binding c-functions or java (I would strongly recommend to not using jni for this anyway!!!) is another animal, we would need a prototype, not needed by c or java compiler and problems would arise at runtime in case of inconsistecies anyway.

My proposals are going in the direction if a prototype is available, it will be check but if no prototype is provided, the binder will try to do a better jab as the compiler could do!!!

Dieter


<Jon>
I have a slight advantage over you on this one Dieter because I was involved in many discussions on how to do the kind of things you're talking about. It is perhaps not as easy as you would have us believe.

It has to be system wide. It has to include every callable IBM object as well as all user callable objects. It would require recompilation of all objects from source because for the most part the information on the requirements is not readily determined from the object itself.

Also "This seems to me very similar to putting the source into the object for debug purpose" - well in most cases the source is not put into the object. A _reference_ to the source file is. Unless listing view is requested of course. But this is just a simple matter of placing data in the associated space. Not a lot of design needed. Note also that it only works if you can recompile.

Just a few other issues off the top of my head:

- Not only do the parameters have to be described but you also need all the other characteristics - CONST, VALUE, DATFMT, and on and on.
- How many signatures do we carry given optional parameters?
- What about C style functions with an "unlimited" number of parms? What does that signature look like?
- If extend the data to allow for passing of a DS array how do I constrain the number of elements passed?
- What do we do about languages like CL and COBOL that have no notion of prototyping? Stop RPG programmers from calling them via a CONST option that would allow for variance in field sizes?

This is a tiny portion of the issues that were raised during the ILE design phase and subsequently. It was a lot of years ago (25+) so I've undoubtedly forgotten many.

</Jon>