Re: CEETSTA API

[Hans Boldt <boldt@xxxxxxxxxx>]

Scott Klement wrote:
> ...
> I won't.  I don't like overloading.  I think it's confusing when the
> compiler gives you an error "procedure not found" and the reason turns out
> to be that one of your variables is a "short" and the procedure was
> expecting an "int".   That's not intuitive.
>
> I don't like it when I search a program for a procedure called "GetCust"
> fix a bug in it, and it has no effect because there's more than one
> procedure called GetCust.
>
> I don't like having to specify a "mangled" name when creating binder
> source, or when using %paddr().
>
> The problems of overloading far outweight the minor difficulties of making
> procedure names like "GetCustByName" instead of "GetCustByNumber"

Procedure name overloading is one enhancement that's at or near the 
top of our "proposed enhancements" list. But at the moment we're 
nowhere near having a solid design for such a thing. All we have now 
are ideas tossed about in the hallway. This present discussion, 
therefore, is incredibly useful for us.

Personally, I too am not a big fan of overloading. But there does 
seem some demand for that type of functionality, and can serve to 
bridge the gap in operational descriptor functionality. Since types 
are known at compile time, there's no really good reason programmers 
should have to query types at run time (except to get the length of 
char parameters, but then again you could use VARYING strings).

Perhaps this is still too early to discuss design (or perhaps not), 
but here are some of our (very) preliminary thoughts. One possible 
design would have you code different procedures each with a unique 
name and parameter signature. (For example, "GetCustByName" and 
"GetCustByNumber".) Then, we'd have some syntax that would alias 
them to one name. That is, an overloaded name like "GetCust" would 
be associated with procedures "GetCustByName" and "GetCustByNumber". 
This would probably be the easiest for us to implement since the 
only new syntax would be a list of aliased procedures. You could 
easily interface to procedures written in other languages, and there 
wouldn't be any "magical" name mangling.

Regarding "short" and "int" possibly being two different types, I 
would guess that we would consider all numerics as being of the same 
type.

Cheers! Hans