It would help if IBM would add the QUAL statement from IBMAP, but that would 
still not give you the OOP paradigm. or scoping.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <[email protected]> on behalf 
of Charles Mills <[email protected]>
Sent: Monday, February 5, 2018 12:44 PM
To: [email protected]
Subject: Re: Fair comparison C vs HLASM

IMHO the biggest lack in HLASM in this sort of regard is lack of variable 
scope. The support for named DSECTs got us halfway there, but symbols still 
must be unique. If I want to define a struct for C I can blithely name my 
variables input and output and count and size and so forth. In an HLASM DSECT I 
have to "fake" scope by naming my symbols CM_input, CM_output, CM_count, 
CM_size and so forth -- and still hope for the best -- there is still no 
guarantee of no name collisions.

The assertion that you can do OOP in HLASM just reflects the poster's lack of 
knowledge of OOP. To your list, add inheritance, overloading, virtual 
functions, ...

I guess you can kind of do inheritance in HLASM. You could define your own DCBD 
extensions and piggyback them on the end of the IHADCB DSECT -- whatever 
additional fields you wanted to associate with a DCB such a buffer pointers, 
counts, NOTE words, etc. In a sense you have defined a child class of IHADCB. 
You could then GETMAIN storage for this combined DSECT, kind of like 
instantiating a child class. (Yes, many differences. The weakness of my example 
kind of proves the larger point: HLASM is not an OOP language.)

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On 
Behalf Of Martin Ward
Sent: Monday, February 5, 2018 9:32 AM
To: [email protected]
Subject: Re: Fair comparison C vs HLASM

On 05/02/18 15:03, Jon Perryman wrote:
> C has functions to reduce complication. C++ and other OOP languages
> have objects. Assembler can easily do this thru macro's and it has
> other tools to greatly reduce complexity.

How do you define a function using assembler macros?
How do you define objects? In particular, how do you stop the programmer from 
taking the address of an object and examining/modifying the object's internals 
without using the defined interface?

Reply via email to