🚀 go-pugleaf

In article <1183@ncis.tis.llnl.gov>, turner@lance.tis.llnl.gov (Michael
Turner) writes:
> A typical problem is:
> 
> 	float x[MAX_POINTS], y[MAX_POINTS];
> 
> where everything refers to the global arrays x and y, rather than defining
> 
> 	typedef struct {
> 		float x, y;
> 	} point;
> 
> and supplying a bunch of operations on "points", independent of a
> global data structure.

But given the language capabilities (or lack thereof), what's so bad
about this?  One can adopt a convention that "points" are just
"integers" (a la pointers) and provide all the operators one would
expect to find on points (e.g., a primitive constructor, 
additional constructors like 'int pt_add(int p1, int p2)', observers,
and so forth).  Of course, the programmer has to keep track of what's
"free" and what's "used" (or maybe write a little "storage allocator").

> This is not the best example.  Perhaps a FORTRAN
> programmer could come up with a better way to encapsulate the concept of
> point in FORTRAN.  I know, however, that I tried to write modular code
> in FORTRAN for many years, and never felt satisfied with the level of
> abstraction that I reached.

Aside from the above, there may not be much else one can do--if
FORTRAN doesn't support the linguistic features you want, you simply
have to impose some conventions on the code you write.  But don't
listen to me, I haven't written a FORTRAN program in at least 10
years.

> Michael Turner
> turner@tis.llnl.gov

John Baugh
jwb@cepmax.ncsu.edu