You rank importance, in the following manner:

1. Reliability
2. Maintainability
3. Performance (this is NOT where most applications fall short or cost money)

I don’t necessarily disagree with you, however sometimes you do have to sacrifice a lesser “important” bullet point for another.

One way to sort of compromise on this issue would be to set some sort of flag, that way introspection could be turned on/off at will.

Introspection in this case, only benefits you while you are developing. Having runtime introspection happening in a live, production release version of an application does you no good and it will just eat up unnecessary resources.

So, let’s say you have a class, idk, let’s just include this functionality as part of a Debugger class, so you have a static var Debugger.INTROSPECTION_LEVEL = “2″; // 0, 1 or 2

Where 2 would be the highest level of introspection, 1 would be basic level and 0 would be none at all.

This way, after you are done developing and ready to push a build, you just set Debugger.INTROSPECTION_LEVEL = 0 and all the performance issues go away.

Just thought I’d share my two cents.

Greets

Second,

protected function doSomething(): void
{
 throw new IllegalOperationError(”This method must be implemented in the concrete class.”);
}

… is not the same as introspection as it does not produce an error until the function is called — the worst possible case in my mind.

I agree with the other posters when they say that Adobe needs to provide an abstract class naively in the language, however, they do not and there are some things you need abstract classes to do (being a C# programmer professionally I really miss this functionality).

Additionally, I always see a good number of people complaining about the “cost” of introspection. Honestly, I use it a lot and RARELY see a serious performance hit (in which case I disable and find another way). However, I think it is backwards to consider performance first and functionality second (when performance is not necessarily going to be an issue). In my not so humble opinion most developers focus WAY to much on performance given the power of the average PC/Server. After getting your code to work, the important factors in order should be:

1. Reliability
2. Maintainability
3. Performance (this is NOT where most applications fall short or cost money)

On the other hand, I believe the compile time error is important and does address the first 2 issues. Without that, the next best thing is to throw an exception at runtime and as soon as possible. In fact, in my own solution, I use even MORE introspection and find all the classes that extend the “MyConcreteType” at initialization and throw exceptions BEFORE the application even fully starts. This makes development, maintainance, etc pretty easy and adds only a mere second or two to my init process (unlike say drawing the controls which takes much longer =P)

Dont fear introspection! I have seen a lot of slow buggy flash/flex applications and more often than not they are slow because of “clever” UI design decisions.

protected function doSomething(): void {
throw new IllegalOperationError(“This method must be implemented in the concrete class.”);
}

protected function doSomething(): void {
	throw new IllegalOperationError("This method must be implemented in the concrete class.");
}