Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!gatech!rutgers!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Can you nest subroutines in C?
Message-ID: <7223@cbmvax.UUCP>
Date: 6 Jul 89 17:07:49 GMT
References: <18215@usc.edu>
Organization: Commodore Technology, West Chester, PA
Lines: 74

in article <18215@usc.edu>, papa@pollux.usc.edu (Marco Papa) says:

>>Pre-initialization is a nicety, not allowed in M2 because there is no way to
>>type the data.  This is a restriction that I understand will be/has been
>>lifted.  However, pre-initailization is not a conceptual tool.  It can always
>>be translated to a series of assignments, or a number of other methods can
> 							  ^^^^^^^^^^^^^
>>be used to init data.

> C'mon. SURE you say. The answer is NO, you can't do it.  And the result of this
> can be devastating for a large project.  M2 like Pascal REQUIRES you to write 
> CODE to initialize all your variables that need initialization.  Think for 
> example of all the menus in a program: you'll need one line of code (that
> dereferences a pointer or accesses a field) for EACH field in EACH of the 
> Menu item. 

Not necessarily.  In many cases, you will, but for something as repetitive and
well defined as menu-building, you'll build a set of constructor functions, 
and then build each menu entry with possibly a single function call.  I took
this approach in C++, even though I could have used static menu declarations,
and I'm currently of the opinion that at least with the present OS, static
menu declarations are bad medicine.  For example, if I want to insert a new
menu entry at any level, all I do is insert the new function call; all other
menu declarations stay the same.  And what I type is typically something
like this:

	// C++ Menus code fragment

	void Proj_Save_As(), Proj_Save(), Proj_Load();

	menu->add("Project",MENU);
	menu->add("Save As",ITEM,Proj_Save_As);
	menu->add("Save",ITEM,Proj_Save);
	menu->add("Load",ITEM,Proj_Load);

	// ...

This allows menu construction to be as dynamic as you like.  So all the sizing 
and locating of the menus is done at run time.  Which means I automatically
and painlessly adjust to the font in use, among other things.  And the menus
are completely position independent -- no need for some giant nested switch
statements.  

> If you have ever seen a "large" PASCAL program there is ALWAYS a 
> HUGE file with all the initializations.  This is enough a reason to not make 
> me consider M2 for any serious programming.  

There are certainly some very important requirements for static data allocations
that can't be handled by clever constructor functions.  For example, you may
want to include lots of image data, which would be real ugly to build one word
at a time in a constructor function, and hard to change once entered that way.
Though in reality, something like that doesn't really belong as a C static
declaration, either, since while C makes it prettier, it doesn't make it that
much prettier.  What I'd really want is a conversion utility that'd build me
an image object file directly from the IFF file.  That gets added to the
makefile, and changes in the image then happen as soon as I exit DPAINT,
not some minutes or hours later after the image is automatically or manually
converted to source code of some kind.

So some initializations are going to be between these extremes, and much more
ugly in M2 than C, though I don't think the number of these is as great as
everyone currently writing C with lots of initializations seems to think.

> Lack of it is just dreadful. 

Well, I always wonder whenever anyone tries to convince me that the lack of 
something is a feature.

> -- Marco Papa 'Doc'

-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
           Be careful what you wish for -- you just might get it