> Is my assumption about this error being specific to function arguments correct?
A similar error may be reported if the return types are not compatible. > Do you have any thoughts on implicit “as” for function arguments to make this more useful for things like event handlers? I'd like to think on it for a bit. -- Josh Tynjala Bowler Hat LLC https://bowlerhat.dev/ On Tue, Jan 27, 2026 at 9:47 AM Harbs <[email protected]> wrote: > Agreed. The feature is useful even for just case 3. I will try to adopt it > for those cases and see how that goes. > > Is my assumption about this error being specific to function arguments > correct? > > Do you have any thoughts on implicit “as” for function arguments to make > this more useful for things like event handlers? > > Maybe something like: > addEventListener(“change”,function(event:!ValueEvent):void{}) The > exclamation mark (or something else) can tell the compiler that a subclass > is acceptable. > > > On Jan 27, 2026, at 7:37 PM, Josh Tynjala <[email protected]> > wrote: > > > > Yeah, I think that a "this" type, similar to TypeScript's, could be > useful > > here. I've always liked that feature. > > > > I think that adding a "this" type should be relatively straightforward. > At > > least compared to the effort of adding function type expressions. The > > tricky part is figuring out which class should be resolved based on the > > context where the method is called or the property is accessed. My > initial > > thought would be a couple of months of development and testing. > > > > We probably shouldn't delay a release to add it, though. > > > > -- > > Josh Tynjala > > Bowler Hat LLC > > https://bowlerhat.dev/ > > > > > > On Tue, Jan 27, 2026 at 2:19 AM Harbs <[email protected]> wrote: > > > >> For case 1, Typescript has a feature which would work nicely. You can > use > >> “this” as a type declaration and it is resolved to the currently used > type: > >> > >> https://www.typescriptlang.org/docs/handbook/2/classes.html#this-types > >> > >> How difficult would it be to copy that feature for ActionScript? > >> > >> Harbs > >> > >>> On Jan 27, 2026, at 10:50 AM, Harbs <[email protected]> wrote: > >>> > >>> I wanted to discuss this in a dedicated discussion because the details > >> will get involved: > >>> > >>>> Hmm. I’m not sure it’s working as I’d expect. > >>>> > >>>> In Core, there’s TaskTest which has this: > >>>> > >>>> > >>>> [Test(async,timeout="50")] > >>>> public function testPromiseToTask():void > >>>> { > >>>> var resolvePromise:Promise = new > >> Promise(function(resolve:Function, reject:Function):void{ > >>>> resolve("resolved"); > >>>> }); > >>>> var resolvedTask:PromiseTask = > >> promiseToTask(resolvePromise); > >>>> > >> resolvedTask.done(function(task:PromiseTask):void{ > >>>> assertEquals(task.result, > >> "resolved"); > >>>> }); > >>>> resolvedTask.run(); > >>>> } > >>>> > >>>> The compiler is now complaining: > >>>> > >>>> Implicit coercion of a value of type > >>>> (task:org.apache.royale.utils.async.PromiseTask)=>void to an unrelated > >> type > >>>> (task:org.apache.royale.utils.async.IAsyncTask)=>void.(1067) > >>>> > >>>> A PromiseTask extends AsyncTask which implements IAsyncTask. > >>>> > >>>> I think that should be allowed. > >>> > >>> > >>> I think I understand why it’s working like that, but we want a feature > >> which is more useful than annoying. > >>> > >>> A function has two parts: 1. The arguments 2. the return value. > >>> > >>> When passing a function into a client, the client is a consumer of the > >> return value, but a “producer” of the arguments. Since the function is > >> expecting a more specific type than the “client” is producing, that > might > >> cause a type mismatch. My assumption is that this error is specific to > >> parameters and not return types. > >>> > >>> Now, while this behavior makes sense from a type-safety perspective, > I’m > >> not sure how useful it will be practically. The typescript type system > >> often tends to be annoying enough that people often just revert to using > >> “any”. I’d like to find the right balance of type safety and usefulness. > >> With that in mind, I’d like to lay out where I see this feature being > used > >> and useful and figure out if we have those bases covered. I’m going to > >> discuss specific cases because that’s easier for me than discussion the > >> abstract. > >>> > >>> 1. AsyncTasks take callbacks which are called when the task is done. > The > >> callbacks are always called by passing in the task in the task instance. > >> The methods (done and exec) are defined in the base class and we don’t > want > >> to redefine those for every subclass. The callback is handled > differently > >> for each task, so the specific type is important in the callback > definition. > >>> > >>> 2. Event callbacks. All EventDispatchers dispatch events which are of > >> type Event. Specific classes will dispatch more specific events. It’s > >> useful to make sure that event listeners are the right shape. It would > be > >> even more useful to know which events should be handled for specific > event > >> listeners. > >>> > >>> 3. Runtime swappable utility functions which calculate some value. (One > >> example of this is labelFunction.) The return type of these functions > >> should be well defined. The arguments should be pretty well defined as > well. > >>> > >>> The first case is not working very well with the current > implementation. > >> By definition, the type supplied to the callback will always be the > type of > >> the specific instance of AsyncTask. Ideally we should have a “this” > type we > >> can declare which would be inferred from the current instance. > >>> > >>> The second case is a more difficult problem. The specific event type > >> dispatched cannot be known because a single class can dispatch different > >> event types depending on the specific event. I’m not sure how it’s > possible > >> to even decorate all the options. Maybe if we had union types we could > do > >> something. For this case it feels like we need some way to declare a > type > >> in the function parameter that’s explicitly telling the compiler “I know > >> this type is more specific than what’s expected, but that’s OK”. I do > think > >> that it should have an error if it doesn’t match the less specific > >> definition though. > >>> > >>> For the third case, I think the implementation as it is, is fine. > >>> > >>> Thoughts? > >>> Harbs > >> > >> > >
