Hahaha, don't worry about me and my opinions mate! Every "rule" has exceptions, and I haven't seen your component so I can't know if there's actually a better way to do it. Also I know the problems you get with MXML components, often you don't get a chance to overload the "correct" method because of the way the MXML compiler works, or other things like that.
-Josh On Thu, Aug 7, 2008 at 3:29 PM, Daniel Gold <[EMAIL PROTECTED]> wrote: > 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:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On >> Behalf Of *Josh McDonald >> *Sent:* Wednesday, August 06, 2008 6:31 PM >> *To:* flexcoders@yahoogroups.com >> *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] >> >> > > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
