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

Jim Stuttard jim.a.stuttard at gmail.com
Tue Aug 12 08:28:51 UTC 2014

On 08/12/2014 08:55 AM, Wojtek Narczyński wrote:
> On 12.08.2014 05:31, ok at cs.otago.ac.nz wrote:
>>> 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.
> Take a VAT Invoice as an example. You will have:
> Invoice, InvoiceBuilder,
> InvoiceLineItem, InvoiceLineItemBuilder,
> InvoiceCustomer, InvoiceCustomerBuilder,
> InvoiceSummary, (no Builder, as this is calculated)
> (many, many more classes in a realistic system)
> Now, where the rather complex validation belongs? Optional / mandatory 
> requirements, lengths, ranges, regexps, control sums, field 
> interdependencies, autocompletes, server sent notifications? Where to 
> put all of this? To regular classes, to builder classes, or to both?
These sound like cross-cutting concerns. I found this paper on monads 
and mixins for AOP.



More information about the Haskell-Cafe mailing list