A while ago a friend and I were having a discussion about the use the private and protected access control attributes in AS3. While I stated that you should always try to write your code as open as possible as to make it flexible, he said that you should always make your code closed unless it was explicitely designed to be not so.

I think the open/closed design principle makes a good compromise: “open for extension, closed for modification”.
What it means is that code should be written so that other programmers can easily add functionality by subclassing your classes (extension), while at the same time ‘private’ stuff like errors will have to be fixed within the original class (modification).

About a week ago someone asked me through the comments-section of a previous post if it was possible to use the DistortImage class with non-embedded (runtime-loaded) images.

Here’s an example:
DistortImage dynamic loading demo
DistortImage dynamic loading demo source

NOTE: I wrote that the code added to the mxml-file in a bit of a rush, it is by no means an example of best practices or what properly written code should look like. Forgive me

In the source-code (dynamic.mxml) I put some extra comments in an attempt to clarify where this code differs from that in the mxml-file of the original demo.

As you can see most of the new lines of code are spent on actually loading the external bitmap, only two of the last lines of Actionscript (where it says “fetch BitmapData”) are essential to the preparation of the bitmap-data.

Last tuesday a bunch of other students from school and I took a traintrip to Amsterdam to see Daniel Dura, Sakri Rosenstrom and Serge Jespers talk at Beyond Boundaries Amsterdam.
At 8 in the morning I met up with Arno at the trainstation in Leeuwarden, just in time to eventually be really late for the first lecture by Sakri. So here’s what the day looked like:

» ..read on

Before coming up with a solution for binding read-only accessors a few months ago, I had already tried out various alternatives, among which the following (which was later also pointed out by others through the comments):

However, the problem here was that Flex throws an error saying "1000: Ambiguous reference to someProperty" whenever you try to use the setter.

After reading a post by Adam Flater I decided to start looking through the documentation and found out that this is in fact a known compiler bug:

174646: If a class contains accessor functions with different access control namespace attributes, (for example, aprotected setter and a public getter) using one of them causes a compile-time-error, for example,Compiler-Error 1000: Ambiguous reference to myVar
The workaround is to rename your getter or setter function to avoid the mismatch.
Common Flex 2 compiler errors and known issues

This bug doesn't seem to have been fixed in any of the Flex 2 hotfixes, and neither in the Flex 3 Beta (thanks to Wietse for testing). Let's hope the folks over at Adobe are going to do something about it..

You may have noticed that when using the @see tag in your ASDocs, that it uses the actual hyperlink-address as a text.
In short, stating @see com.somedomain.MyClass will look somewhat like ../../com/somedomain/MyClass.html in the generated documentation.

However, some time ago I discovered that you can actually use aliases to make your @see's look prettier, just enter an alias after a whitespace on the same line (tab, space, etc.):

..but of course you can use any alias you want to, except for linebreaks and all that nonsense