[Haskell-cafe] The Good, the Bad and the GUI

[ok at cs.otago.ac.nz]

> If you declare Person class
> in Java, you automatically get a thingy that you can readily use in UI
> construction, because all the fields can temporarily be null, even the
> required ones. In Haskell you'd need two data types: the usual proper
> Haskell data type, and another which wraps every field in Maybe,
> facilitates editing, validation, etc. Perhaps it would be possible to
> generate one data type from the other, or generate both from a common
> specification.

You seem to be referring to the "incompletely initialised object"
anti-pattern.  The books I have about concurrency in Java/on the JVM
strongly recommend making Java objects immutable when you can.

Even in Visual Basic, if an object is "constructed" via a lengthy
sequence of steps, it is good design to distinguish between two
different things": a fully constructed Foo object and a FooBuilder
object.  Sometimes they need to be the same object, but there really
do need to be two *interfaces*.  Once past the construction phase,
you want to KNOW that the object is fully constructed, and there are
things the constructor might do that you DON'T want other objects to
do.

Reflecting on the use case you are talking about, it seems to be
that there are two conceptually very distinct objects here.
There is a FooForm object which is intimately connected to the
user interface and may only partially describe a Foo, and there
is a Foo object which is *not* connected to the user interface
or if it is, is connected in a quite different way, exposing
quite different behaviours.  Reflecting further, suppose I fill
out a form and press a button to commit this object, then I
edit the form to be a little different, and press the button
again.  Creating a new *object* by revising a single *form* is
clearly distinct from *editing* an existing object.

What I think about this, therefore, is that you want a clear
distinction between FooForms and Foos (at the very minimum a
distinction between FooForm and Foo interfaces) no matter WHAT
kind of programming language you are using, and I don't see
Haskell as anything special here.

> Let me write the same thing in other words. It is not controversial to
> say on this list that specifying what is correct means, is a good idea.
> But for GUIs, in addition to the strong type, you need another relaxed
> type to hold the values temporarily, until the human manages to deliver
> correct data, often by trial and error.

In short, we agree, that is indeed *ANOTHER* type.

Not only may a FooForm not yet hold information a Foo needs,
a FooForm may hold information that a Foo does *not* need.
For example, a FooForm might need to hold on to some credentials
to prove that it is authorised to create Foo objects, whereas a
Foo object might not.

In Smalltalk, Java, C#, &c one might look at ways of automatically
constructing FooForms from Foo classes + annotations.  Using some
sort of generic processing, one could also do this in Haskell.
Having two classes/types does not have to be twice as much work.