[Info-vax] Access to _all_ VMS system services and library functions from DCL ?

[David Froble]

Simon Clubley wrote:
> On 2017-07-11, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>> On 2017-07-11 07:00:51 +0000, Simon Clubley said:
>>
>>> On 2017-07-10, David Froble <davef at tsoft-inc.com> wrote:
>>>> Well, not just for DCL.  Have defined blocks of data for each system service.
>>>> Either I allocate the memory, (probably best) or have the system service
>>>> allocate the memory.  Then jam it full of all data provided by that system
>>>> service.  Sure would do away with item lists, at least to some extent.
>>>>
>>> A single block of data which is directly accessed is too limiting and 
>>> will cause massive maintainence problems as structures are changed and 
>>> field sizes changed in the future.
>>>
>>> This will lead to a different version of the data block for every 
>>> change in the future and all these versions would have to be kept 
>>> around in the future as well as the code to populate them.
>>>
> 
> [snip]
> 
>>>> If I can "include" the data structure in my programs, and then 
>>>> reference the  data by name, sure would make things simpler.
>>> And what about when the data block is changed because a field is 
>>> expanded (for example) ?
>> If the block is opaque to the end user ? similar to how BASIC tends to 
>> treat descriptors, scaled up to cover the system service data returned 
>> by itemlists  ? it'll work very close to what David is considering.   
>> Add in the ability to delay accessing the underlying data until its 
>> requested by the user and the storage and performance details are far 
>> less egregious than fetching everything.
>>
> 
> Unfortunately, I got the distinct impression that David and others were
> looking for something similar to a giant struct to be returned without
> any layers of abstraction and for the variables within the struct to be
> directly accessible by the application.

Not sure what type of abstraction you might want here, but, yes, that's exactly 
what I'm suggesting.  A structure, with variable names for the fields int he 
structure, readable be the application.  It would be rather meaningless to write 
into the structure.

>> Yes, there's overhead on message-passing designs such as where David is 
>> headed here, but there's overhead in writing and processing itemlists 
>> too.   Trade-offs can change over time, and the holes in the existing 
>> OpenVMS design ? from back when memory was tight and processor 
>> performance was lacking ? are quite apparent.
>>
> 
> I've never seen David advocate for message-passing and OO designs before.
> David tends to advocate for a very different style of coding.

I've felt that things like OO are extensions of what many people have developed 
as just "good coding practice" through the years.  I really don't have much use 
for those who then take good ideas and go to what I consider extremes.

As an example.  A former co-worker, many years ago, embraced "structured 
programming".  Now such is usually good coding practices.  But the "purists" 
declared that a GoTo statement was not allowed.  That is an extreme.  This 
co-worker refused to use GoTo, even when directing execution to program exit. 
Instead, he used GoSub to that location, even though there would never be a return.

I embrace what I see as good practices.  I'm not sure what style of coding you 
think I embrace.