I think Josh stated the fundamental problem here: commitProperties() is not a place for setting properties, it's a place for commiting them once they've been set.
Gordon Smith Adobe Flex SDK Team ________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Alex Harui Sent: Wednesday, August 06, 2008 7:35 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Must call super.commitProperties at END of overrided commitProperties when extending TitleWindow? 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] <mailto:[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] <mailto:[EMAIL PROTECTED]>
