[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
  fields.

* 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.


Regards
Andre