aharui commented on issue #78: Assign to Boolean variable does not convert to true or false, breaking loose comparison with == URL: https://github.com/apache/royale-compiler/issues/78#issuecomment-461597374 We could try to do a survey, but I'm pretty sure a significant number of booleans won't need to be initialized. So far, we've managed to get a lot of code running without initializing them. I think it is rare except in setters. I never said it was "strange". AIUI, an uninitialized boolean takes zero bytes in the final output. The cost of initializing a boolean is at minimum, something like: `b.c=0;` // b is 'a.prototype'` PAYG philosophy encourages solving the actual problem instead of adding more code just in case, so one option may be that for `(someBoolean == someOtherBoolean)` We generate: `(||someBoolean == ||someOtherBoolean)` Or maybe even: `(someBoolean === someOtherBoolean)` Or offer choices on what to generate. We could offer a warning as well so folks can consider how they want that code to work. Maybe they will just use the warning to manually initialize the backing variable in a setter. Royale has a JSONReviver already, but may need a JSONReducer that doesn't just hand over the object tree to JSON, but adds other information like classAlias similar to how AMF works so that the right instances of ValueObject are created in reading/writing JSON. That JSONReducer could know that a field is boolean and handle it correctly. FWIW, I've often thought about pre-processors and other template-like features for the compiler. It is always frustrating to have to type a new getter/setter pair. The compiler folks were very against preprocessors, but in some ways you could argue that the code generated by [Bindable] is effectively coming from a preprocessor. So a more complex solution could be to introduce [GetterSetter] metadata that takes an optional change detection method and have the compiler generate the right code including declaring and initializing the backing variable. There is a half-way point where the compiler initializes backing variables used in compares by assuming the backing variable will have a name that matches the property name with a leading or trailing "_". Also, FWIW, I've wondered if the compiler were to generate such code, whether the compiler should generate code that tries to reuse strings. I'm not sure how well ZIP compression works with string variants, but each setter with change detection usually has 3 string variants: the name of the property, the name of the backing variable and the name of the change event. The point is that these ideas address the actual problem, which that uninitialized booleans have zero cost and work fine in most cases, but there are specific places where special handling is needed.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
