I'm convinced there's no point in allowing a mismatch.
I just looked at the flex source for Panel.titleIcon and it looks like it's
more a factory class than an embedded asset class. It's used like this
if (_titleIcon)
{
titleIconObject = new _titleIcon();
titleBar.addChild(DisplayObject(titleIconObject));
}
So I think we should just stick to the Flex way in this case.
Re Container.icon I think using Object is a good idea.
On 2021/10/17 20:36:48, Greg Dove <[email protected]> wrote:
> 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?
> > >
> >
>
