/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Iconara » Architectural Atrocities

Archive for the 'Architectural Atrocities' Category

Architectural Atrocities, part 11: Not yet another namespace construct

Gumbo introduces many new classes, some of which are re-implementations of existing Halo classes (and thus have the same name). In order to disambiguate between Halo and Gumbo, Gumbo classes are prefixed to avoid collisions. Gumbo components that have Halo equivalents, like Button, List and CheckBox, are now prefixed with the letters “Fx”. This means in MXML, a Gumbo Button would be instantiated via the <FXButton /> MXML tag, and a Halo Button would continue to be instantiated via the <Button /> MXML tag. Additionally, the new animation classes in Gumbo also follow the same prefix policy. A Gumbo resize effect is instantiated via the <FxResize /> MXML tag while a Halo resize effect is instantiated via the <Resize /> tag.

From Gumbo Component Architecture

So what are they going to do for Flex 5, use “Fx2″?

Seriously, ActionScript has three* namespace constructs already, why introduce a fourth? Using prefixes is a hack to get namespaces in language that lacks them (like C or PHP), but packages were invented to solve exactly this problem.

In MXML it’s dead simple to use namespaces and prefixes to differentiate between different components with the same class name (e.g. <mx:Button> vs. <fx:Button>). The only place where it gets a bit messy is in ActionScript, but it seems to me that it is a fringe case when you want to juggle both a Halo and a Gumbo button or both a Halo and a Gumbo list in the same class (a Halo list and a Gumbo button, sure, but that wouldn’t cause a clash). I can see it happening, but not often enough to warrant such an ugly solution as this.

I remember when AIR was called Apollo and the WindowedApplication class was called ApolloApplication. This is the same kind of short-sightedness.

* Three namespace constructs: packages, namespaces and XML namespaces (which are different from packages since you can manually flatten a package structure with a manifest, e.g. the Flex namespace contains both classes from mx.core and mx.controls, and others).

Update: Adobe has decided to revert the decision of prefixing the new Gumbo classes. Good for everyone.

Architectural Atrocities, part 10: Cairngorm’s Service Locator

In this installment of the Architectural Atrocities series I’ll continue on the Cairngorm theme. This time it’s something that is truly an architectural atrocity if there ever was one, and one of the ugliest things I’ve seen in such a high profile piece of software that Cairngorm is (a fact that still baffles me): Cairngorm’s Service Locator.

Read the rest of this entry →

Architectural Atrocities, part 9: Cairngorm’s Model Locator pattern

From time to time I re-read the introductory articles on Cairngorm just to remind me of why I don’t use it and never will. This installment of the Architectural Atrocities series is a critique of the Cairngorm framework, and the Model Locator pattern in particular.

Read the rest of this entry →

Architectural Atrocities, part 8: is there no equality?

The collections in Flex are good as data providers for list and tree components, doing the dirty work of making sure that the components know of changes made to the underlying data, but frankly they suck at most other things. Most importantly they suck at being collections. In this post I’m going to show you why and how to alleviate the problem somewhat.

Read the rest of this entry →

Architectural Atrocities, part 7 / MXMLC WTF (6): Some types are less equal than others

An object of type Number, int, uint and Boolean cannot contain null. You may find it obvious, but I find it weird and disturbing. Disturbing enough to include it in my series on architectural atrocities in ActionScript.

Read the rest of this entry →

Architectural Atrocities, part 6: No, that is not a singleton

What does the classes Stage, Key, Mouse, Selection, ExternalInterface from the ActionScript 2.0 API:s have in common? They are bastadized singletons.

The really sad part is that of the five, three are still in the API:s in ActionScript 3.0 and of those Mouse and ExternalInterface are still bastardized singletons. Stage has been refactored completely and Key and Selection have been replaced or removed.

Read the rest of this entry →

Architectural Atrocities, part 5: Interfaces in AS3

This is the fifth post in the Architectural Atrocities series and now the time has come to scrutinize ActionScript 3.0. The item of discussion is interfaces and how they are used in the ActionScript 3.0 API:s.

Let me start with an OO-maxim:

If you prefix your interfaces with “I”, you have no idea how to use them

Read the rest of this entry →

Architectural Atrocities, part 4: the biggest of them all

In this the fourth post of my series Architectural Atrocities in ActionScript, I refer you to the blog post Raising Hell by Zwetan Kjukov, in which he explains the biggest atrocity of them all: ActionScript 2.0, the beast.

The main point is in a sidenote

ActionScript 2 is not a real class-based language, only it’s syntax is class-based

and that’s the kernel of the poodle, AS2 is weakening syntax sugar on top of a more powerful language, namely JavaScript.

Architectural Atrocities, part 3: Side effects

In programming, “side effects” refers to things that happen when you call a function or method, besides the returned value. For example, a method might change the UI, log a message or write to a database, and yet return a value at the same time.

Read the rest of this entry →

Architectural Atrocities, part 2: The filters property

Today I wrote a filter tween component. In it self it wasn’t very hard, but ActionScript didn’t help very much. I never cease to be amazed over how bad the ActionScript API:s are (I have a feeling this is how most of my posts are going to start).

Take the filters property of the MovieClip class, you would expect the filter API, which came with Flash 8, to be modern and object oriented, but no. It’s a property, it’s an array that I have to manage by myself, and what’s more: it actually returns another array from the one I set.

Read the rest of this entry →