I believe the committee defining the next version of Ecmascript is considering support for nullable and non-nullable types. - Gordon
________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Freiman Sent: Wednesday, September 19, 2007 12:24 PM To: [email protected] Subject: Re: [flexcoders] nulling primitive data types 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] <mailto:[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] <http://yahoogroups.com> ] 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.
