[Info-vax] VSI: "Official 8.4-1H1 Launch"

[Stephen Hoffman]

On 2015-06-15 23:05:04 +0000, mcleanjoh at gmail.com said:

> I guess itemlists were a reasonable approach when memory was in short supply.
> 
> These days, with greater memory, would you opt for a fixed structure 
> per call (e.g. getjpi_struct) with a flag value (composite of OR'ed 
> item codes) to say what data should be loaded into that structure by 
> the called routine?  Or would you do it some other way?

I happen to like the OO messaging approach.  It's at least as flexible 
and quite probably more flexible than itemlists, and it's cleaner — 
that deals with the API flexibility, with whatever the data that should 
be returned, as well as releasing the memory when you're done with it.  
 Delegates when you want to be notified of something.  I've posted an 
example of a request for the host names else-thread.

Somebody that knows Microsoft .NET can provide what that platform does 
here; I'd expect it's roughly similar.

For not-OO code on OpenVMS, the equivalent lib$ calls are easier for 
most operations, but they're still pretty clunky.  Particularly around 
the memory management.  (Yes, I know that the system services can get 
more than one item in each call.)

For the existing itemlist morass, it'd be nice if there were wrapper 
calls or macros or compiler assistance; something that generated a blob 
on the heap and dealt with the creation and linkages and cleanup for 
you.  An itemlist parser for use in the called code, too.  But I'd 
spend little time on the older tooling.  There's not really any fixing 
it in the existing application source code and you're going to have to 
support the old ways for the foreseeable future, and if you're going to 
expend the effort to start draining the swamps, then rethink the 
interfaces and go all in and expend it on a different and better 
approach.  Make it so that the folks with the old code see how much 
less code and how much easier it is, and really want to move forward.

I don't expect to see something like Swift or Objective C on OpenVMS, 
but it'll be in the range of possibilities on x86-64.

-- 
Pure Personal Opinion | HoffmanLabs LLC