[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/
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,
* There seems to be a more powerful and simpler alternative:
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.