Abstract classes

[Mathieu St-Gelais <ma...@gmail.com>]

Hi guys. First, I'd like to congratulate the team for yesterday's release.
You're doing a fantastic job with this project.

I have a question I've been wanting to ask you for a long time: are there
any plans to introduce abstract classes in future versions of Flex? With
the new compiler maybe? I've been working a lot with Flex in the past 2
years, making relatively big applications with advanced architectures, and
I really miss the abstract class (like you have with Java for instance):
http://en.wikipedia.org/wiki/Abstract_type. I end up creating a class and
an interface, with run-time exceptions to prevent instantiating the "base
class" directly. It works well, but isn't as clean as an abstract class
would be.

If no work has been done in that direction, does anyone know how much work
adding such a feature represents?

Thanks a lot!

Mat

Re: Abstract classes

[Alex Harui <ah...@adobe.com>]

On 8/7/13 6:29 AM, "Mathieu St-Gelais" <ma...@gmail.com> wrote:

>Hi guys. First, I'd like to congratulate the team for yesterday's release.
>You're doing a fantastic job with this project.
>
>I have a question I've been wanting to ask you for a long time: are there
>any plans to introduce abstract classes in future versions of Flex? With
>the new compiler maybe? I've been working a lot with Flex in the past 2
>years, making relatively big applications with advanced architectures, and
>I really miss the abstract class (like you have with Java for instance):
>http://en.wikipedia.org/wiki/Abstract_type. I end up creating a class and
>an interface, with run-time exceptions to prevent instantiating the "base
>class" directly. It works well, but isn't as clean as an abstract class
>would be.
>
>If no work has been done in that direction, does anyone know how much work
>adding such a feature represents?
IIRC, there are two approaches: 1) try to extend the language by adding
new keywords like "abstract", 2) Use metadata to decorate the class
definition.

The target runtimes are unlikely to be upgraded to support new language
features, so regardless of which approach we choose to take, the net
result will be a class with code exactly as you have written it.  So
really, any changes we make are not actually to the language, but just
making different codegen.

I haven't looked to deep into it, but a language change requires changing
the parsers and also has the side-effect that any previously existing
ActionScript books and documentation won't describe these keywords.

I'm not a fan of metadata, I think it is way overused, but the compilers
already know how to generate code for [Bindable] so adding [Abstract] may
not be all that hard, but adding compile-time checking that you have
overridden every [Abstract] is additional work.

So, it isn't high on my personal list, but open a JIRA request and see how
many votes you get, and/or get the compiler code and try to make the
changes yourself.

-Alex