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]
