[Info-vax] OpenVMS Development Annoyances

[Stephen Hoffman]

On 2019-04-09 20:20:35 +0000, Arne Vajhj said:

> On 4/8/2019 11:09 AM, Stephen Hoffman wrote:
>> Another and longer-term consideration here is around what will probably 
>> be an eventual migration toward what .NET and such provide; toward OO 
>> interfaces into the system and the libraries.  The compatibility with 
>> the "new" calling standard that'll eventually be arising here.  Those 
>> changes are obviously not going to happen anytime soon, but remaining 
>> compatible with the solutions for C++ would be preferable, as the rest 
>> of the OpenVMS APIs are made more compatible with OO environments, 
>> including with the eventual OOBASIC implementation and support that'll 
>> keep David entertained.
> 
> I agree that long term such a new OO SYS API is needed.
> 
> C++ support is obvious.
> 
> Pascal and Basic could probably be extended to support the necessary OO 
> features (other have done so).
> 
> Fortran, Cobol and C I don't see go there.

I'm not expecting to see OOFortran and OOCOBOL arrive on OpenVMS in the 
near future, but porting over newer llvm-based compilers will 
eventually and inevitably bring over newer standards to OpenVMS.

> But that API would not contain descriptors so I don't see any 
> compatibility issue with just picking something for descriptors in 
> current API.

This hypothetical new calling standard is necessarily contending with 
the old APIs for the foreseeable future, with objects containing 
descriptors, itemlists and related baggage.

If you're mixing your OpenVMS C++ code with some not-OO Pascal source 
code for instance, you're going to be working with different 
descriptors than with BASIC.

I'd rather not have to re-do the source code yet again with the arrival 
of some hypothetical new OO calling standard, and I'd rather not be 
adding more baggage for compatibility.

Dealing with the old APIs and the old source code is going to be enough 
baggage.




-- 
Pure Personal Opinion | HoffmanLabs LLC