royale-compiler icon indicating copy to clipboard operation
royale-compiler copied to clipboard

Typed Functions with signatures

Open Harbs opened this issue 4 years ago • 12 comments

Currently in ActionScript, it's only possible to declare function signatures for methods and package level functions. It's not possible to declare signatures for variables and function paramters. The best you have is var foo:Function or function foo(fun:Function):Function{}.

This in my opinion is the biggest hole in the ActionScript type system. I have felt this lack for a very long time. It's very commonly felt in event handlers, but possibly a bigger issue is that it makes ActionScript a poor choice for functional-style programming.

If I had only one feature I could add to the language, it would be typed functions with signatures.

The exact syntax is less important than the type safety. My initial suggestion would be Vector style angle brackets with content like you'd use for an interface. Something like this: var fun:Function.<(ev:Event):void> or function foo(callback:Function.<(handler:IAsyncTask):IAsyncTask>):void{}.

Harbs avatar Jan 18 '22 08:01 Harbs

This is definitely something I have always wanted to see in AS3.

If this were to be implemented, one thing that should be allowed is something like this:

var fun:Function.<(ev:Event):void> = function(ev:Object):void {};

To be clear, Event is a subclass of Object, so that function should be allowed for the same reason why you can assign an Event instance to a variable of type Object.

var obj:Object = new Event();

With return types, there's a similar situation, but instead of superclasses, subclasses would be allowed.

var fun:Function.<():Object> = function():Event {}

joshtynjala avatar Jan 18 '22 20:01 joshtynjala

var fun:Function.<(ev:Event):void> = function(ev:Object):void {};

@joshtynjala would that not be?:

var fun:Function.<(ev:Object):void> = function(ev:Event):void {};

greg-dove avatar Jan 18 '22 21:01 greg-dove

No. I think the point was that you should be able to override the type restrictions by explicitly using Object. That's a general AS3 feature available elsewhere.

Harbs avatar Jan 18 '22 21:01 Harbs

No. I think the point was that you should be able to override the type restrictions by explicitly using Object. That's a general AS3 feature available elsewhere.

yes, but this: var fun:Function.<(ev:Event):void> is strongly typed to Event as a parameter, not Object. So it should accept function values with ev:EventSubclass, but not Object. That is generally how these things work, I think.

greg-dove avatar Jan 18 '22 21:01 greg-dove

OK. I see what you mean. I'll leave it to Josh to answer for himself... 😉

Harbs avatar Jan 18 '22 21:01 Harbs

As I was writing that, I wondered if it would be clear enough using Object, or if I should use more specific classes. I guess I should have been more specific after all.

Let me fix that. This should be allowed:

var fun:Function.<(ev:MouseEvent):void> = function(ev:Event):void {};

I don't have the types backwards.

Consider the following, which is allowed in AS3 code that exists today:

function myListener(event:Event):void {}
myListener(new MouseEvent());

This is why myListener should be allowed to be assigned to var fun:Function.<(ev:MouseEvent):void>. Because the type is Event, it can accept any subclass, including MouseEvent..

Function types in Haxe and TypeScript both work how I describe. Here's a TypeScript example:

let myListener1: (event: MouseEvent)=>void = function(event: Event) {} // no problem!
let myListener2: (event: Event)=>void = function(event: MouseEvent) {} // error!

joshtynjala avatar Jan 18 '22 21:01 joshtynjala

Thanks for the explanation, @joshtynjala, it's been a while since I used this stuff in Haxe, and I didn't use TypeScript yet.

I am used the declaration/assignment pattern of var name:Type = value of Type or SubType

And it seems inverted here when looking at it (without thinking too deeply about it I guess).

So probably I am also getting confused about runtime vs. compiletime behavior here.

for var fun:Function.<(ev:MouseEvent):void> = function(ev:Event):void {};

fun(new Event('blah')) will fail at compile time, which is the main point, I guess.

greg-dove avatar Jan 18 '22 22:01 greg-dove

Yeah, it's kind of tricky. With function types, you need to think about what arguments get passed in when the function is called to understand what other function type can be assigned.

The other way around wouldn't work:

var fun:Function.<(ev:Event):void> = function(ev:MouseEvent):void {}; // this should error, but what if not?
fun(new FocusEvent()); // whoa, that's not a MouseEvent!

joshtynjala avatar Jan 18 '22 22:01 joshtynjala

An aside: Why does Vector have the syntax Vector.<Foo> instead of Vector<Foo>? I've always found the extra dot weird and hard to remember...

Harbs avatar Jan 19 '22 11:01 Harbs

You'd need to ask someone from Adobe about the full details, but I recall that there was some concern about whether Vector<Foo> might have some kind of potential syntax ambiguity, and they felt that it was safer to use Vector.<Foo> instead.

joshtynjala avatar Jan 19 '22 17:01 joshtynjala

I guess we should stick to the TypeScript form maybe? ES4 was fine too, but I am confused as to what is best. I have supported () => T in my parser also, but previously I have gone into function(...): T.

type F0 = () => void;
type F1 = (...a: Array) => void;

Also, ABC does not support function types, so the compiler should erase them at the output ABC in the meanwhile.

hydroper avatar Nov 20 '23 15:11 hydroper

Just to update, I've updated AS3Parser to comply with ECMAScript 4 syntax for function type expressions.

type F = function(): *
type F = function(Number=): *
type F = function(...[Number]): *
type F = function(...): *

hydroper avatar Apr 11 '24 21:04 hydroper