- Is there any way for us developers to influence this decision making process? - What is the current position this committee holds? - What do other languages do? - Is it possible to make a Non-primitive extension type of a nullable int, Number, Boolean in future releases (thus remaining true to the current way of doing things, but still leaving some room for developers)?
We use some VOs in Caringorm to handle some sql result sets when we found out that an int column with the value of null came back as 0 in flex. This puts us in the position to either make all VO variables of type String (problems because 1- the int/Boolean is not a string and 2- hard to work with strings as int/Boolean) or scrap VOs all together in favor of using regular objects (error prone, not typed, no auto complete in flex builder, etc.). As far as I know, the idea of "not yet determined" and 0 are not equal. Reminds me of Schrodinger's Cat. Some part of me cares what is "right", but mostly I just want it to work without hacking both flex and server ends. Thanks. --- In [email protected], "Gordon Smith" <[EMAIL PROTECTED]> wrote: > > BTW... Adobe is on this committee along with other companies. Our plan > is to adopt what they decide, but to influence the decision process. If > they go for nullable types, you'll get nullable types. If they don't, > you won't. We're taking language compliance seriously. > > - Gordon > > ________________________________ > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Gordon Smith > Sent: Wednesday, September 19, 2007 1:22 PM > To: [email protected] > Subject: RE: [flexcoders] nulling primitive data types > > > > I believe the committee defining the next version of Ecmascript is > considering support for nullable and non-nullable types. > > - Gordon >
