IMO it doesn't make sense to create support for mismatched accessor types. This could technically be supported in javascript, but has always been a compiler error for actionscript, and I suspect a runtime error if bytecode was generated to attempt it for swf.
Basically actionscript 3 as a language does not allow different typing for getter and setter. Because javascript is untyped, it is technically possible at that implementation level, but it would be unusual I think to try to have it possible at actionscript level. This mismatch is now possible with Typescript (which only targets javascript), however it was only added this year, it was not the case prior to that, afaik. The issue I think that we need to consider is whether we want 'Class' typing here at all. If the majority of the use here is with Embedded assets, and if those don't work, we need to decide a) Is it important to find a way to make Embedded Assets work that create a 'Class' for each embedded asset, similar to legacy Flex compiler (but likely as base64 data for js) or b) Do we switch to Strings (asset url) only in each case or c) Is there scope for some compact data format that 'profiles' the asset (via some image java lib) providing pre-load data like width and height as well as the string url which gives some sort of immediate layout/measure support before the asset is loaded or d) other ideas.... For icon/titleIcon properties etc, what I'd suggest is that typing the accessors as Object instead of Class allows the possibility for any of the above options because the variations could be supported in the setter. And for most porting of Embedded assets it (currently) involves switching them to String urls, so that would IMO be the best option for now, but I am keen to hear what others think. My 2 cents Greg On Mon, Oct 18, 2021 at 1:26 AM Yishay Weiss <[email protected]> wrote: > As a compromise it may be useful to be able to have the setter receive an > Object and the getter return a Class, which is actually an Object (and > typically a String), while annotating with ignore coercion. I think we > would have a type mismatch issue though, so I wonder if there's a way > around that in the compiler. Anyone know? > > On 2021/10/17 12:16:28, Yishay Weiss <[email protected]> wrote: > > Container.icon is Class, which is good in Flex for embedded images, but > AFAIK not useful for Royale. Do you guys think we should change the type to > a String at the risk of creating some compile time errors? > > >
