This project has moved and is read-only. For the latest updates, please go here.

Last edited Feb 28, 2011 at 9:19 PM by BertrandLeRoy, version 1


wbmstr2good Mar 3, 2012 at 10:32 PM 
As with other development tooling or style, there is often times more than one right answer. As such, I can think of quite a few situations where composing objects and behavior at runtime might be a good fit. For instance, if data that I'm using is large and constantly changing its structure, order, or otherwise unreliable, writing concrete implementations might be difficult or time consuming. A prefered approach may be just to provide an interface that describes only the data I need without requiring the ceremony and additional development time introducing formal DTO objects for only the unreliable portions. This saves time by allowing data i need to be parsed using redundant boilerplate parse code encapsulated within a single implementation provided by Clay. The benefit is realized once you consider that i was free from worrying about typos introduced when using a hand created map and that Clay has cross-checked the materialized data against a strongly typed interface which I then use in the rest of the code.

That's choice, and choice is good.

gliljas Aug 31, 2011 at 9:17 AM 
Yes, this is what we want.

Sleeper16583 Apr 15, 2011 at 9:09 AM 
And is this what we want? Less compile time typing/checking, more loosely typed stuff. Types are like unit tests. They take time, but they reduce errors.