Architechtural Atrocities, part 1

Introducing the first article in the series Architectural Atrocities in ActionScript. In this series I explore the inconsitencies, oddities and idiocies of the ActionScript API:s. It’s likely to become a long running series, as I don’t see any obvious limit other than the API itself. By the way, who is the architect behind the ActionScript API:s? If anyone knows, please tell me, and I will put him or her on the list of people never to hire.

In this first item on the infinite list, let’s explore the oddities of the BitmapData method applyFilter.

public applyFilter(
	sourceBitmap : BitmapData,
	sourceRect : Rectangle,
	destPoint : Point,
	filter : BitmapFilter
) : Number

Can anyone see the problems here? The Image API is new in Flash 8, so there is absolutely no excuse to use this bastard of a mix between procedural and object oriented design. Why have an object oriented environment, if you can’t handle the basics of object oriented design?

For those of you who haven’t had your morning espresso yet, this is what’s wrong:

1. Look at the first parameter, this is an instance method on the BitmapData class, yet you have to specify which bitmap data instance to work on. What would it mean to write bitmap1.applyFilter(bitmap2, ...)? It makes no sense. It looks as if it’s a class method or a function, but it’s not.
2. Look at the return type, it’s a Number. The documentation says “Returns [...] a number that indicates whether the filter was applied successfully”. Oh, yeah! C-style error reporting, how very this century. The language supports exceptions, and the Image API is not backwards compatible, so why on earth not use them?

The architect of the ActionScript API:s and the Image API in particular seems to be ignorant of the basics of object oriented design. There is no excuse for not knowing these things.

I guarantee that I will be back shortly with more Architectural Atrocities.