🚀 go-pugleaf

> /* Written 10:55 am  Mar  3, 1986 by crocker@ihwpt.UUCP  */
> > > ... a post by me about structs vs. classes ...
> 
> "By definition, a struct is simply a class with all members public,
> that is
> 	struct s { ...
> is simply shorthand for
> 	class s { public: ...
> 		
> Structures are used when data hiding is inappropriate."
> 
> By the above definition, a "struct" type is not necessary per se,
> and no one is forcing you to use them.  I think that they add to the
> "compatibility" of C and C++.  By calling something a "class"
> implies the use of the data hiding features; calling something a
> "struct" implies openness.

Let me rephrase: why not have added `private:' and `public:' keywords to a
struct declaration, so that
	struct s { ...
is equivalent to 
	struct s { public: ...
and the new construct
	class s { ...
is simply
	struct s { private: ...

I suspect "class" is used in the tradition of Simula.

I find the lack of a `private:' keyword a bit jarring. I am sure eventually
to want to write large classes where each private component has a 
corresponding public element - actual fields, and the abstract operations
that manipulate that field.
	class c {
		private: data_aspect_1;
		public:  operations_on_data_aspect_1;
		
		private: data_aspect_2;
			 data_aspect_3;
			 /* 2 and 3 together implement abstract aspect A */
		public:  operations_on_abstract_aspect_A;
	}
In C++ I must group all the private aspects together, far away from
the corresponding public operations.
	class c {
		data_aspect_1;
		data_aspect_2;
		data_aspect_3;
	    public:
	        operations_on_data_aspect_1;
		operations_on_abstract_aspect_A;
	}

This strikes me as resembling the situation in Wirth-Standard Pascal, where
VAR declarations had to precede all PROCEDURE and FUNCTION declarations, 
preventing functions from being written next to the data structures they 
manipulated. I say this in the past tense, since most Pascals now permit 
arbitrary ordering and intermixing of LABELs, VARs, PROCEDUREs, FUNCTIONs, 
and CONSTs in a block.

Of course, you could say that I should never write large classes, that they should always be broken down into, or built up from, smaller classes.