Update 4/2/09: Hopefully it is obvious, but in case anyone stumbles upon this post unknowingly, please note that it was an April Fools joke.
I hate explaining or pointing out jokes. It's like having to bribe the teacher to pass your child because the kid couldn't master Kindergarten on their own merits. But in this case, I'd like to be clear to avoid any confusion over what Flex actually supports and why.
Like any good joke and some former presidents, there is a small bit of truth behind it, but a lot of it's just hooey. Except for item 6, which really is the current state of the Spark component names. And the part about the community. We really do have posters of them up on our walls, at work and at home. Every one of 'em.
What's in a name? A rose by any other name would still draw blood...
If you’ve paid any attention to the development of Gumbo, the next release of the Flex platform, you probably know that there was a dust-up about the naming of the new components and effects in Gumbo. In technical terms, this is known as a ‘kerfluffle’, but it generally boiled down to a process of the community beating up the Flex team on a regular basis.
Now we on the Flex team love the community: we have pictures of them in our cubes, we try to friend them on FaceBook (though they usually reject us), and we generally suck up to them every chance we get. In fact, we have an internal contest of collecting signatures of community members. Deepa’s currently ahead, but we suspect some are forgeries.
Because of our abiding, nearly predatory love for the community, we wanted to make things right. So when people found fault with our proposed component names, we pissed and moaned and generally felt sorry for ourselves. Then, in a feat of maturity heretofore unknown to engineers, we sucked it up and tried to fix it.
I’d like to lay out the general history of the naming proposals, and then show the final result. I’m sure you’ll agree with us that it’s really fantastic now and that you now respect and admire us for the changes we’ve made. And who knows – maybe we can even get your autograph.
For the descriptions below, I’ll focus (get it? focus! Just another in a hilarious serious of UI toolkit-related word plays. God, I love working on this technology!) on the ‘button’ component, as it’s representative of everything else in the toolkit, from components to effects to that utility class that calculates Pi to 1,547 digits (using the circular reasoning algorithm).
1. First attempt: Button
In the beginning, there was a word, and the word was Button.
Unfortunately, that word was already taken by Button in Halo. But surely nobody would care when the new Spark button was going to be so magnificent that nobody would ever care about the old Button again, right? So we named our new Spark button ‘Button’ and went on our merry way.
But the tools, Lo did the chafe and grumble. What about applications that used both Halo and Spark components? What to hint? What to complete? How to distinguish?
Clearly, another solution was desired.
2. Second attempt: Synonym for Button
Well, since Button was taken, we needed a different name for the same darned thing. We considered several alternatives, including:
- ThingThatPushes
- RectangularClickyThing
- BetterButton
- OnButt
- PressMe
- Presser
- ComponentFormerlyKnownAsButton
The last of these was the leading contender for some time. We even developed a custom glyph for the object, but it turned out the glyph could not be represented in unicode and that the class became so long that it bloated our SWF sizes by 10x, so we sadly gave up on this angle and searched for something else.
3. Attempt the Third: Suffix
It turned out that ‘Button’ really was the best name for something that was, well, a button. We realized that we needed something distinguish the new from the old button, however, so we considered suffix text, including:
- ButtonNew
- Buttonn (repeat the last letter, like Panell, Checkboxx, etc. This broke down when legal objected to our use of ‘Canvass’ as being obscene and derogatory toward Canvas-like objects).
- ButtonSpark
- ButtonButton
- Button2
All of these would have been possible, but we gave up on this path due to what we in the trade call “The Icky Factor.” We did try out these various alternatives in front of a live studio audience. They threw up.
4. The Fourth Attempt: Prefix
Well, if a suffix wouldn’t do it, surely a prefix would. So we tried several, including:
- JButton: Hans suggested this one. It seemed very familiar to some of us, like coming home. But execs rejected it on the paltry basis that the letter J has nothing to do with Flex.
- SparkButton: This variation had several advantages:
- It would promote the branding of the new Spark theme in Gumbo.
- It had a perky ring to it
- It would help developers practice their typing skills by requiring these extra five letters for every component and effect.
Nonetheless, this variation was killed in committee for being too easily confused with the UI components released by the Scatological Processes of Anitomically Correct Koalas agency.
- SButton: This was a leading contender for a while, but finally withered and died when someone realized that the new HitTester component would suffer with the preceding S.
- FxButton: Finally we had a winner.
FxButton had clearly won. It had the multiple merits of being easy to type, indicative of the Flex platform, and having that cool letter "x" in it that all hip products nowadays must have. Obviously people would love FxButton and would shower praise and autographs upon us.
5. The Fifth Attempt: The Community Hates It
It's not clear what happened: Do international keyboards lack the F or x keys? Did people not enjoy the extra typing practice it gave them? Did they not enjoy the clever but subtle pun that the new component was a "fix" for the old one (we laughed for weeks over that one. Oh, we have a jolly old time in the Flex offices, that's for sure!).
Whatever the reason, the community hated it. They railed upon our decision, they cast aspersions on the Fx prefix, and they scrawled mean words about us on bathroom walls in engineering institutions everywhere.
So we swallowed our pride, along with a case of scotch, and headed back to the planning room for
6. The Sixth Attempt: Goto (1)
It turned out that 'Button' was really the best name for Button after all. The nuance was that we needed to set up separate namespaces, a common pattern in Flex applications already, to deal with the name collisions. So we did this, setting up a namespace for the core language, another for the old Halo components, and a third for the Spark components, and then went through the joys and pleasures of renaming all of our classes again, enabling our QE department to rewrite tests and generally feel fulfilled and fully employed. As a result, we ended up with a Halo button that you would use by calling <mx:Button/> and a Spark button that you would create by calling <s:Button/>. They're both buttons, they just live in different namespaces. Like twins that are raised in different cultures, one that grows up to be a cop, the other a criminal. Then they meet by chance during a bank job and wind up pointing guns at each other, each having to make his own choice whether to take out his brother for the sake of the life he's chosen, yet clearly hearkening for the shared bonds and experiences that genes bring.
7. The Final Chapter
So that's it, that's the state of the renames: We now have the same names for the same components in Halo and Spark, except for the different namespaces to qualify them accordingly.
But that was yesterday. Then, just today, someone suggested something that is so huge, so fundamentally awesomely stunning and cool that we're rewriting the SDK and all the tests again and have now checked in the final fix to the whole thing: self-obfuscating code.
The original problem to solve was that we didn't want to confuse people by having the same name for different things. In the meantime, developers of web applications like to obfuscate their code to make it harder for shady engineers (perhaps their twins, raised in a different culture to a life of high-tech crime) to steal their ideas. In the interest of both of these goals, we now introduce:
<mx:Bxgthnr5gl!8x/>
Every night, the build auto-generates a random series of ASCII characters for each Spark component, thus guaranteeing that each component name is different from other Spark component names, from the old Halo component names, and from anything else that might otherwise confuse developers. Developers can now be assured that component names are completely unique. And since the generation is done as part of the build, we also auto-generate the ASDocs at the same time, making it easy for developers to figure out what the correct component names are for the build that they are using.
No more "Which Button do I use?" or "What was that prefix again?" or "I hate when other people can read my code!" or "Gee, I wish names were randomly generated so that I could practice my random keystroke typing speed!" Now, with the new Fully Obfuscated Occasionally Long component names, we expect Spark and the Flex Gumbo platform to be the favorite platform for RIA developers everywhere.
