Sam, I think that you're out of luck when it comes to Boolean. There is no undefined boolean value, and boolean can only ever be equal to true or false, nothing else. I'd second the recommendation in the case of number of using NaN to represent undefined values (and for that reason use Number in place of int/uint whenever I need undefined numeric values, though MIN_VALUE or MAX_VALUE sounds like equally good choices).
I think the *correct* way of handling this will require a lot of model work, but it'll make it airtight in the end (and the API for the model will be clean even if the internals are "dirty"). What you're really talking about are two issues, one of serialization and one of Flex API. In regards to serialization, you'll more than likely be translating these values into strings to transmit to the server, in which case you simply just use a "NULL" string value (just like SQL) to indicate nulls and handle them appropriately on the server side. In regards to API of your Flex classes, this is the approach I've taken: in your model, create getters and setters for the various properties you want to be nullable. The getters and setters should return the correct static types. For each property you add an additional method named something like "resetXXX" or "clearXXX" that sets the property to the undefined value (since you can directly set the properties to undefined values). Internally to your model class, you store the private backing variables for the properties as plain old Objects, assigning them null is they're undefined. Your getters/setters will deal with all of the messy casting/boxing the types to and from the backing object. The one convention you need to establish is what happens when a client of the model attempt to get an undefined value. In most of my scenarios, an undefined value meant the value what either a "default" or an "inherited" value, so I always had a valid value to return even when the actual model instance's value was undefined (think prototypes). If getting an undefined value is a mistake, then you'll probably want to throw an exception *and* provide a method for the user to validate a property (isValidXXX, etc.) so that folks don't have to always try/catch around your exception for nulls. Yep, it does make the implementation of the model very messy (or busy, rather), but the API to the model remains clean and accurate to the application's design. Troy.
