🚀 go-pugleaf

This is required strictly from a practical viewpoint.  The problem is
simply that changing a header --in any way-- makes every dependent code file 
recompile.  That includes adding the occasional forgotten
function, used only when coding the public methods of the class.  
So one is often faced with a nasty choice -- write a
tiny function and pay (half hour, hour, more?) or write ungood 
code.  Self-discipline requires the function, but it does hurt.  Can we
avoid it without changing all the nine zillion forms of make?  

One can touch back the header, but that's also unclean.  Also, some
integrated environments, certainly Borland's, don't always respect the touch.

A similar, but much worse, problem occurs with templates.  It's worse
because the template code is so much more extensive.  No problem in
a library, of course, but if one is writing one's own templates it
gobbles up rebuild time.  I beat this one by breaking up a template into
whatever.h and whatever.hh.  whatever.h  has the declarations, whatever.hh
has the function definitions.  Then there's a single source file for each 
template- generated class, instantiating all the functions.  It's only 
these files which #include whatever.hh, and only these which recompile
when it changes.

Could we do the same for non-template headers?  Only with some awkardness
and danger.  This is pretty ugly:

class XX {
	int		dataMember1;
	void	functionMember1();
  public:
			XX() { - - - }
#if ALL_OF_XX
	#include	"restOfXX.h"
#endif
};

Now your Makefile dependencies need not usually list restOfXX, but you're
terribly exposed to natural errors.  The compiler and the pre-processor
don't talk to each other, so there's no way to forbid data members, virtual
functions, etc. in the conditional region.  So this won't do.

So perhaps we could have a language feature like this:

class XX {
	int		dataMember1;
	void	functionMember1();
  public:
			XX() { - - - }
};

When needed (probably in restOfXX.h):

struct XX << {	// '<<' means that this is an extension
	int		functionMember2(int) {dataMember1 = 0;}
}

This looks risky -- after all, you could have different extensions
in different places.  That's no more likely than having different 
definitions entirely in different places.  You can do it and the
language lets you get away with it, for a while 

Extensible definitions are less risky.  The compiler can easily keep bad 
things out of the extension -- no data members (mess up space calculations 
based on the unextended version), no virtual functions (ditto),  Static 
data members look OK.  

Is the world ready for this?

--
rp

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]