Wednesday, April 1, 2009

Post: Fix Prefix

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:

  1. 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.
  2. SparkButton: This variation had several advantages:
    1. It would promote the branding of the new Spark theme in Gumbo.
    2. It had a perky ring to it
    3. 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.

  3. 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.
  4. 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.

11 comments:

Unknown said...

You should have followed JavaFXs lead and just launched Spark with no visual components whatsoever. Prefix problem solved!

Unknown said...

How are you guys planning to handle Style Declorations? Will you be adding namespaces to the stylesheets

fx:Button {
color: #cc0000;
}

Pete Farland said...

We'll put our CSS Namespaces specification up on open source soon, but we'll be using the CSS-3 proposal for @namespace and the corresponding prefix syntax.

For the default namespace in a style sheet...

@namespace "library://ns.adobe.com/flex/spark";
Button { color:#CC0000;}

If you needed to disambiguate between components in two namespaces, you'd use prefixes:

@namespace s "library://ns.adobe.com/flex/spark";
@namespace mx "library://ns.adobe.com/flex/halo";

s|Button {color:#CC0000;}
mx|Button { color:#00CC00;}


Note that the mapping of these namespace qualified type selectors to ActionScript class names happens in the same way that MXML tags are mapped to ActionScript classes. That is, information from SWC catalogs and top level manifests configured for namespaces in /frameworks/flex-config.xml.

Robin Harrison said...

I like the idea of the Fully Obfuscated Occasionally Long component names, but I generate my all my Flex code from one 14.6Mb XML file.

Would it be possible to have the obfuscated names deterministicly created based upon measurable, but randomised data, perhaps weather patterns, or migratory paths of birds?

Harry B. Garland said...

How's it going to be for somebody learning Flex for the first time starting on version 4? There will be so much archeology in the autocomplete and docs that it's going to be very confusing for a lot of newcomers.

Time for a clean break?

I hope there's an option to just totally exclude the Halo library when developing a new Flex 4 project so that every time I start typing <but..., I don't need to use the down-arrow key to specify for autocomplete that I'm using a Flex 4 button. (Especially since the packages listed in alphabetical order will default to Halo (mx) instead of Gumbo (s)).

Chet Haase said...

Harry: Yes, this will be simplified for first time users of Flex4, or for anyone using just the Spark component set. But explaining the simplicity angle wasn't the intent of this particular blog...

Anonymous said...

I think you should have stayed with OnButt. Canvass can kiss your OnButt. Yeah. like it.

Anonymous said...

I generally agree with Robin here, but I think that weather patterns aren't really random enough. I would say that you should use the decay of a radioactive isotope.

Also, with this new change, I think that it's important that people use good naming conventions for their variables. Every single variable should be named 'llll', unless it conflicts with a previous 'llll' in the same scope, in which case the names 'lll1', 'll1l', etc, should be used instead. Also, when using the or operator, never leave spaces between it and variables it's comparing. This should ensure well obfuscated code for all involved.

Borek said...

Naming the namespace "s" by default doesn't fix the HitTester problem, does it? :)

Unknown said...

I suppose the program Icon will need to change as well. Fs instead of Fx. That might be shortsighted though. I propose F? This should not be thought of as F question mark. Contrary; it stands for F wild card. A timeless solution with the door open for arguing it should be F*

Dan Orlando said...

I would prefer that the PREFIX itself be randomly generated in the form of F^x, thus suggesting "F of x". X should be calculated using an HMAC-SHA1 algorithm based on the time of day in Kasistan (in the number of milliseconds that have transpired since January 1, 1970 at 12:00am, of course) and the weather in Elbonia. In this case, F will be equal to the centrifugal force of the sun on the earth at that very moment. Now we have obfuscated the actual prefix well enough that if we want to stick with "Button", then so be it :-)

cheers!