/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Iconara » Architechtural Atrocities, part 1

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.

2 Responses to “Architechtural Atrocities, part 1”

  1. Alexander Arendar Says:

    Dude,

    I agree with your point that returning a number is very funny thing and exceptions should work much better. But regarding the first point on sourceBitmap argument… Could you provide your alternative of how the method signature would look like in ideal world? Anyway you need to pass the source bitmap as one of the arguments so seems having it named “sourceBitmap” is not that bad, better than param1 I think :)

  2. Theo Says:

    The point is that the source bitmap is the receiving object, so to apply filters to bitmap1 you write bitmap1.applyFilters(bitmap1, ...).

    Now, the docs say that you can pass another bitmap as the source, but that should have been a separate method. The common case it to apply the filters to the receiving object, so that should be what the method does. Then there could be a applyFiltersWithSource (or whatever) that accepted a separate source bitmap. The architectural atrocity is that the designers of the BitmapData class thought it was a good idea to mix these two together, so that in the common case you have a procedural-style object function where the first argument is the this object.

Leave a Reply