In a little project it would be nice if the built-in types were all you needed. But in a big project, you are probably already creating infrastructure for application specific type conversion for the values used in your domain. Fit needs to access this infrastructure, however it is organized.
People who don't get WholeValue will read lots of little integers and strings from lots of little fields and let the business logic assemble them into meaningful values. But that is a foolish way to program when you have objects. Better to make domain type aware widgets store whole values into domain objects and write the rest of the business logic at that level of abstraction.
I think one reason that people don't get Whole Value is that they are database centric and their database makes them chop their domain values into lots of little integers and strings to store them. I see people refuse to use the abstracting capability of their language and then say that objects don't really work that well. Grrrr.
TypeAdapter is that place between the cell and the check where domain type conversion gets hooked in. I'd hate to see it removed because then Fit would be contributing to anti-abstraction just like the database. I also don't think TypeAdapter has to be big and complicated if you have a powerful language. Java just made a lot of bad decisions in their reflection api that got covered up by having complex TypeAdapters. C# is much nicer where every class (except one) implements parse so there is only one special case in TypeAdapter.
Whole Value is discussed in the Checks Pattern Language: http://c2.com/ppr/checks.html#1
|Last edited April 17, 2005
Return to WelcomeVisitors