@MSGID:
<1d7b21e4-fdd6-4977-bd4e-d923977629bfn@googlegroups.com> b6079374
@REPLY:
<401e5a1f-91f2-4075-a910-ee8455b0fd93n@googlegroups.com> 176768b7
@REPLYADDR robin vowels <robin51@dodo.com.au>
@REPLYTO 2:5075/128 robin vowels
@CHRS: CP866 2
@RFC: 1 0
@RFC-References: 1@dont-email.me>
<5fbb8dcc-d5b9-45a4-9d4f-23caeebc0778n@googlegroups.com> 1@dont-email.me>
<9b605c0b-c8a1-40eb-a73f-428377f906a5n@googlegroups.com> <ee5025c7-3121-4e6d-87a9-f54452f1c145n@googlegroups.com>
<258c15c6-7463-4d80-8326-0016c5a4ff1an@googlegroups.com> 1@dont-email.me>
<401e5a1f-91f2-4075-a910-ee8455b0fd93n@googlegroups.com>
@RFC-Message-ID:
<1d7b21e4-fdd6-4977-bd4e-d923977629bfn@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
On Thursday, 31 August 2023 at 03:13:45 UTC+10, gah4 wrote:
> On Tuesday, August 29, 2023 at 6:47:49 PM UTC-7, Gary Scott wrote: 
> 
> (snip, I wrote)
 > > > It is then possible to write OO code in C, though with a
little extra work that 
> > > you don`t need to do with C++. 
> 
> > Isn`t a single derived type an "OO" concept? I`m still not a fan of 
> > derived types for procedure arguments (e.g. the win32 API...yuck). I 
> > use the extensively for internal "global/common" purposes though.
> As well as I know it, derived types are related to structures in some other 
> languages. I first knew them in PL/I, where I believe they came from COBOL. 
> 
> I believe the Fortran standard also uses the word structure, so I sometimes 
> call them that. 
> 
 > I don`t know the history of OO, and especially when the actual
term originated. 
> I do remember someone telling me about Simula sometime before I knew 
> about C, though wasn`t interested at the time. 
> 
 > I also don`t know the history of COBOL so well, but it does
seem that they idea 
> of keeping disparate date together is important. 
> 
> Looking at it now, you have to wonder what took Fortran so long. 
> 
> But a common idea in a COBOL program might be the information about 
> an employee, such as name and salary, that would be kept together. 
> They would then be read from a file (or in the early days, card) together, 
> and operated on sometimes as a unit. 
> 
> PL/I has stream and record I/O, where STREAM corresponds to Fortran 
> FORMATTED, and RECORD to Fortran UNFORMATTED. RECORD I/O 
> statements only read/write one variable, which is commonly a structure. 
> I believe that also came from COBOL. 
> 
> Note that is especially convenient for I/O, as the data is together. 
> In the usual case, it can be copied to/from byte by byte, without knowing 
> what the data type is. 
> 
> PL/I also has locate-mode I/O, where you access data directly in the I/O 
> buffer, saving the need to copy it. I suspect also from COBOL, though 
> I don`t know that one. 
> 
> Also, COBOL only has one-dimensional arrays. But you can have arrays 
> of structures of arrays of ..., so the effect of higher dimensions. 
> PL/I has, I believe again from COBOL, some convenience in array access. 
.
Multidimensional arrays in PL/I  came from FORTRAN and ALGOL,
but whole array operations and cross-sections of arrays were a
new concept that came with IBM`s first PL/I compiler in c, 1966.
.
The latter features were adopted 25 years later into Fortran 90.
.
> If you have a structure array that might be accessed as x(i).y(j).z(k), the 
> compiler can figure it out if you instead say: x.y.z(i, j, k). 
> Even more, assuming it is not ambiguous, partial qualification 
> allows for z(i, j, k) where the compiler assumes the x.y. part. 
> (PL/I allows for multiple dimensions, but also moving subscripts 
> around and partial qualification.) 
> 
> It seems that some of the OO ideas might have originated in COBOL, 
> and slowly spread until they got named, into other languages.
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441