text: This is far from ideal but after chatting with Ted this is all we could come up with.
  Again because in AS 3.0 all constructors have to be public, it is not possible to create a class that can only be extended without a bit of extra work. If I create a class that should only be extended, then I want it to throw and error if it has been used incorrectly.
  [as]package
  {
  public class Abstract
  {
  public function Abstract()
  {
  if( toString() == “[object Abstract]” ) throw( new Error( “Abstract must be extended” ) );
  }
  }
  }[/as]
  The reason this is far from ideal is that it requires you to hard code the name of your class as the string comparison. If anyone has any other bright ideas I would appreciate it.
  ummm… I always used the ‘sing’ ctrl+space shortcut in eclipse/fdt and just switched it to do this automatically by editing the template. clumsy, but automated.
  Hey Liam
  But if you using FDT then you must be using AS 2.0 which means you can make your constructor private.
  These 2 workarounds are specifically for AS 3.0 where all constructors have to be made public to comform the the ECMA spec.
  [...] Builder Woes Abstract Classes in AS3! by mims I was looking at this blog post by Tink about more strict Abstract constructors in Flash using Errors. I worked out a [...]
  Hi Tink,
  This is as good of a solution as I’ve seen anywhere. After reading about it here and on the Adobe site I set out to implement this and was able to squeeze out a couple of improvements. Most notably, I was able to get this working without using a string comparison!
  Check it out:
  Thanks,
  Mims Wright
  Hey Mims
  I like the solution of not using a String although I think the classes overcomplicate it a bit. I think I’ll be using
  package
  {
  import flash.utils.getDefinitionByName;
  import flash.utils.getQualifiedClassName;
  public class Abstract
  {
  public function Abstract()
  {
  if( Class( getDefinitionByName( getQualifiedClassName( this ) ) ) == Abstract ) throw( new Error( “Abstract must be extended” ) );
  }
  }
  }
  which should be templateable i think.
  [...] this is particularly useful is not executing error handling like similar to that found on Tink’s blog about simulating Abstract Classes by throwing errors, removing trac [...]
  I’ve followed your abstract class implementations for awhile now. Came up with an idea on how to do abstract method implementation checks at runtime using the introspection API. Check it out at:
  I haven’t come up with an alternative to hardcoding the method names. It certainly would increase type safety if this were the case.
  [...] 3 does not have native support for abstract classes so I have used the trick provided på Tink. Having the abstract class makes it easier to write policy handlers and saves yo [...]
  [...] ow new Error(“AbstractExample must not be directly instantiated”); } toString Approach @ Tink public function AbstractExample() { if(toString() == “[object AbstractExmample]“) throw new [...]
  [...] like this solution best as it doesn’t rely on strings for comparison as in Tink’s example. His method is shorter, and easier for typing. It’s down to personal preference really. [...]
  You really shouldn’t forget that I can just try catch your constructor and make the object anyway.
  Maybe just check “Object(this).constructor” ?
  [as]
  public function Abstract()
  {
  if(Object(this).constructor==Abstract){
  throw( new Error( “Abstract must be extended” ) );
  }
  }
  [/as]