I definitely put a HUGE comment when moving that call to super to the end of commitProperties, with a note that I should look into refactoring things to not set any properties in commit. It may have been the only comment I wrote this year.
My logic was that I WAS propagating changes in commitProperties, and one of those changes had the effect of modifying a property of the super class, which just didn't cross my mind as being problematic at the time. The title of this window was a combination of different properties, and rather than calling updateTitle() in each setter, I decided it made the most sense to do that in commitProperties so I could catch if any of the properties changed and have only a single location calling that function. I slowly try to migrate older, or more rapidly developed components to the invalidation mechanism, but run into problems when it's at the franken-stage where it's half MXML with bindings, and half invalidation flags and commitProperties. Problem being that the setter will fire bindings, but the change won't be fully propagated everywhere it needs to and I get some null or some unexpected value that is only half right and gets updated in the next frame after commitProperties makes a change and causes other bindings to fire. Maybe someday I'll write perfect by the book code from the get go. On Wed, Aug 6, 2008 at 9:35 PM, Alex Harui <[EMAIL PROTECTED]> wrote: > Well, I said you were "strict" and not "wrong". I've heard others say > that super always should be the first thing in an override, but to me, that > means that an override can only add or re-do and not intercept, which is, > IMHO, a valid thing to do for an override. > > If you're that worried about whether you forgot or even intended to call > super, a comment might be in order. Gordon likes comments whenever we > deviate from a pattern like add a listener in capture phase. Sometimes I > actually put them in. > > ------------------------------ > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Josh McDonald > *Sent:* Wednesday, August 06, 2008 6:31 PM > *To:* [email protected] > *Subject:* Re: [flexcoders] Must call super.commitProperties at END of > overrided commitProperties when extending TitleWindow? > > I guess :) > > I just *really* don't like a situation where the position of > super.whatever() affects whether or not it works. Frankly If I were > designing a language super.foo() would be the default, and there'd be a > keyword to block it. > > If super.commitProperties() can be expected to be anywhere inside a method, > you can no longer at a quick glance tell whether or not it's called at all. > > The point I think is that commitProperties() is ideally (correct me if I'm > wrong) for propagating any changed properties on "this" into their actual > destinations, and deciding whether or not you need to schedule an > updateDisplayList() or measure(). Doing anything else, such as changing said > properties should be done where it makes more sense. The idea is that all > the property changes generated by any events dispatched in the last frame > are already completed by the time you get to commitProperties(). And > changing properties inside commitProperties() invalidates this. It seems to > me that whoever decided to ignore invalidateProperties() within > commitProperties() thought something similar. That's probably an arrogant > assumption to make, but I'm a jerk like that some times :) > > Somebody else in 6 months could see super.foo() at the end of your method, > and because it's not in line with the rest of the project, move it back up > the top - who knows how long it'll be before somebody notices that under > certain circumstances the titles on your CustomPanel aren't what they should > be any more? > > -Josh > > On Thu, Aug 7, 2008 at 11:15 AM, Alex Harui <[EMAIL PROTECTED]> wrote: > >> Man, you are strict! There is no reason you can't do work in your >> override before calling super.whatever() >> >> ------------------------------ >> * >> * >> > > > > -- > "Therefore, send not to know For whom the bell tolls. It tolls for thee." > > :: Josh 'G-Funk' McDonald > :: 0437 221 380 :: [EMAIL PROTECTED] > > >
