Constructors, source code, and best practices

In my earlier post What I Hate About Computer Programming, I described a series of failed attempts and work-arounds that I flailed through in an attempt to solve a given problem.

In it, I wrote:

The right time to add these event listeners is when the PitchSlider's instance is done being created. The Slider class' superclass, UIComponent, has a nice little "creationCompleteHandler()" method that's called at just the right time, too.

Well, apparently, the right time to add such event listeners is in the view's constructors, which I would have thought was WAY too early in the construction/initialization process. The constructor happens to be one of the few methods that isn't marked as "mx_internal" (because it can't be, being a constructor, and all).

How did I learn this? By studying the source code to Adobe's Flex framework, which is installed along with the Flex SDK.

I've spent much of the last few days doing nothing but studying Flex's source code. There's no better tool for learning a framework that walking through its source code, both linearly (reading straight through a file) and interactively (stepping through it with a debugger). That's how I learned to use MacApp (the first widely-used application framework for personal computers) back in the mid-1980's. I don't think there were any books on MacApp then; the source was the only info available. You can hardly walk through a bookstore today without tripping over books on Flex, which is great, but nothing beats access to the source code.

As I said about MacApp "back in the day,"

MacApp is not just a bunch of user interface code, it is a library of accumulated wisdom on Macintosh programming.

These days, "accumulated wisdom" is called "best practice," but it's the same idea.

The more things change...