If you look at how Adobe handles nullable booleans in the flash.text.TextFormat class, they use a variable of type Object. So I'd be shocked if there was good way to do this that they simply ignored. I'd say more, but everything I can think of has already been covered in this thread.
- Dan Freiman On 9/19/07, Samuel R. Neff <[EMAIL PROTECTED]> wrote: > > Troy, > > Thanks for the additional comment but remember I am not the original > poster.. someone asked a question for how people work with nullable > primitives and I provided a response on how I particularly do it (which of > course is only one of many possibilities). We've been using MIN_VALUE for > several years in both .NET and Flex and have been extremely happy with the > results. While someone may feel this is not "correct" from some theoretical > standpoint, it works very well, is easy to understand, and doesn't require > mucking with the API and making radical changes to support nullable > primitives. > > Serialization of course depends on the mechanism for communication and in > my case we're not converting to strings, we're not even doing our own custom > conversion at all, we're using Flash Remoting. So having a scheme that > works well with built in serialization made the choice that much easier. > > Again, my comments are only an example of how we do it and I'm happy with > this methodology. I personally believe that adding extra reset and clear > methods for every property just to provide some level of theoretical > "correctness" is unnecessary, makes things run slower, and causes extra > work. However, it is a valid point and suggestion and if you do this and it > works for you, then great, always good to have more opinions and options. > > Best regards, > > Sam > > > ------------------------------------------- > We're Hiring! Seeking a passionate developer to join our team building > Flex based products. Position is in the Washington D.C. metro area. If > interested contact [EMAIL PROTECTED] > > > > ------------------------------ > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Troy Gilbert > *Sent:* Wednesday, September 19, 2007 1:33 PM > *To:* [email protected] > *Subject:* Re: [flexcoders] nulling primitive data types > > 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. > > >
