What I Hate About Computer Programming

By and large, I'm enjoying my return to computer programming after a 17-year hiatus. However, the experience is also reminding me of the things about computer programming that I hated before, and still hate today.

Here's an example.

My PitchSlider component is a subclass of the Flex class named VSlider.  No problems there. In PitchSlider's current implementation, one must specify, in one's application, a "thumbHandler()" function that deals with mouse presses on the slider's thumb (the thing you drag around to change the slider's value, and hence the pitch of the PitchSlider).  This implementation is kinda grungy, because the application using the PitchSlider needs to know a lot about how of the PitchSlider's internal details.  It's a "tightly-coupled" design. What I'd like to do is move the thumb-handling code into the PitchSlider class instead -- hiding it from the application -- and then dispatch a custom event when the thumb is released, advising all listeners that the pitch slider's pitch has changed. This latter approach would enable a looser coupling between the PitchSlider and its container/application, which is a Good Thing.

Unfortunately, writing PitchSlider this way appears to be *&^%$#@ing impossible.

All I need to do is override three methods of VSlider's superclass, named Slider: onThumbPress(), onThumMove(), and onThumbRelease(). My overrides would call the inherited method and then (respectively) start playing the current pitch; change the current pitch; and stop playing the current pitch (then dispatching a custom event indicating the final pitch).  That should be no problem, I figured; this kind of "extension by subclassing" is exactly what object-oriented programming is all about. 15 minutes, tops.

But noooooo.  Inside of the Slider class, these methods are hidden away in a special "mx_internal" namespace. A Google search on "mx_internal" indicated that any method flagged mx_internal is not to be overridden because Adobe (creators of the Flex framework, of which the Slider class is a part) might change its implementation in future, and therefore wants to be able to say "here there be dragons; use these implementation details at your own risk."

Excuse me?  I can't override any of the three methods that uniquely distinguish sliders from all other controls? WTF? When I was napping with Rip van Winkle, did subclassing become passe?

There had to be a way around this. 

Google led me to a discussion of how to get past the "mx_internal" barrier: just import and then use the mx_internal namespace.  Good enough --  I'd use this work-around in the short run to get the PitchSlider working, so that I could focus my attention on learning how to use try/catch blocks or some other more-pressing concern.

But noooooo.  The work-around works when *calling* hidden methods, but not when *over-riding* them. Instead, the compiler barfs an error message that is helpful only as the basis of another Google search.  Googling it, I found an official Adobe bug report saying that the work-around didn't work when using it to override methods.  This required *another* work-around, to wit, omitting the keyword "override" in the definition of the function.

Fine, OK, whatever. Omitting the "override" keyword did indeed allow the code to compile, thus successfully working around the compiler bug. I figured that I was home free.

But noooooo. Running the application threw up a run-time error, telling me that I had illegally overriden a Flex method.

*&^%$#@er - *&^%$#@ers!

Apparently I was simply not going to be allowed to do the obviously-right thing by overriding these *&^%$#@ing methods.

Deep breath. Om mani padme hum. I am but scum on Buddha's foot; all striving is vanity; and this *&^%$#@ing approach isn't helping me to attain any *&^%$#@ing enlightenment anyway, so forget it and move on (as the Dalai Lama might say).

Time to go to Plan B: have my PitchSlider add event listeners to itself, so that it can "notify itself" when its *&^%$#@ing super-class is done handling thumb press, movement, and release actions.

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.  I figured that I would just override that method to install my event listeners. It's not an "mx_internal" method, either, so that should work.

But noooooo.  creationCompleteHandler() is marked as a "private" method, which means that it can't be overriden, either.

*&^%$#@er - *&^%$#@ers!

I was never a great computer programmer.  I was good, but never great.  And I know that I've been out of the loop for an outrageously long time, so...perhaps there's some new way to accomplish this task that would be patently obvious to anyone lacking grey hair. I'd welcome the opportunity to become enlightened.

But *&^%$#@us *&^%$#@ing *&^%$#@st, I absolutely HATE this cascading series of problems, work-arounds, and work-arounds for work-arounds, with each level delaying the release of my product by hours or even days.  I just want things to *&^%$#@ing *work*.

(It's exactly this kind of short-tempered frustration that drove me to create the iGetIt! Music System in the first place, of course.  If I'd been more patient, I would have just learned music the way everyone else did...the hard way.)