[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problems with field initialization

I am not sure that nontrivial field initialization contributes /necessary/ complexity.

Having said that, the paradigm for field initialization seems wrong to me. It imposes arbitrary limitations which I believe to be simple to overcome in an alternative design suggested at the end of this post.

But first, the problems with the current approach:

* It arbitrarily limits the kinds of computations that can be performed
  during initialization of a field.  For example, one cannot reuse
  intermediate results needed for more than one field.  Each field has to be
  recomputed from scratch from the inputs.

* It has the wrong granularity.  A common use case it cannot handle
  is a consistency check of the arguments before computing
  the individual fields.

  A related use case is where the constructor has optional arguments,
  where the number of arguments need to be determined before computing the

* A record type definition declares an implicit constructor procedure.
  However, the actual body of the procedure is interspersed with other
  syntactic elements, which seems gratuitously complex to me.

* The design requires record declarations to be a new binding form.
  Apart from the lack of economy this entails, this binding form has
  an somewhat unusual, and therefore guaranteed to be confusing to many,
  scoping rule.

* There seems to be a more powerful and simpler alternative:

Alternative Suggestion:

 Instead of having a separate <init expression> for each field, one could
 simply have an <expression> for the constructor, which should evaluate to a
 procedure that returns the computed fields (using VALUES, for example).

 This would solve all the above problems.  The overall gain in power and
 simplicity would be, in my view, significant.