Some X++ construction issues.

[Michael McClary <node!michael>]

Synopsis:

 - Heap allocation of instances of classes could be restricted
    - To prevent heap allocation of things that shouldn't be on a heap
    - To restrict object creation to functions that know how to do it,
      i.e. pseudoconstructors.

 - Default copy constructors can be suppressed.  Doing so might catch
   errors.  (Or it might cause problems.  I ain't tried it yet nohow.)

 - Should pseudoconstructors be static member functions?  (Shouldn't
   we be making more use of static members and member functions?)

Was reading chapter 12 of the ARM, and made a few observations.  I see
no need to DO anything just now (except document them).  The following
should be taken as observations-in-passing, not something that's been
carefully thought out.

All of these are of interest mainly to people programming directly in X++.
Any changes that DID affect smalltalk would most likely just require a
minor change to the translator.

----

Just as construction of objects can be restricted (to children,
friends, etc.) by making the constructors private or protected,
heap allocation can be similarly restricted by declaring private
or protected "operator new()"s to override the default allocator(s).
This might be a good thing to do on classes that shouldn't ever be
on the heap.  It can also be used to restrict instance creation to
the pseudoconstructors.

Similarly, default copy constructors and default assignment can be
restricted.  This might be wise on things that publish their address,
and thus shouldn't be moved or copied with wild abandon.  (We currently
suppress assignment, but apparently not default copy construction, on
Heapers.  This prevents overwriting, but not movement.)  However,
suppressing default copy constructors might break some current
initialization, and the main error it would catch (copying an object
rather than a pointer to it) might be uncommon or nonexistent.

Ellis and Stroustrup think pseudoconstructors should be static member
functions of the classes they construct, in contrast to our use of
naked global functions with standardized names.  I'm inclined to agree
(as a sytlistic matter, not because of some change in functionality),
and to suggest that the same applies to most functions-about-the-class
that in smalltalk would be messages to the class object.

One feature that might be gained by converting to static member
psudoconstructors would be the ability to write a pair of X++
class-declaration macros that would automatically declare and define
them, as a side effect of declaring and defing the constructors proper.
Another feature of note is that such functions would automatically have
access to private or protected versions of "operator new()", per the
above comments about restricting object creation.

Changing to static member functions would have the (undesirable?)
side-effects of:
 - giving the functions access to the member variables of the objects
   to which they relate, and
 - changing the syntax of calls to these functions.

	michael