What I meant was that it is populated from embedded assets. titleIcon="@Embed(etc...
That approach, or 'binding' to an embedded Class const. So I don't understand the difference you expressed for titleIcon, because this is exactly the scenario I was meaning where class typing would typically be a string url in royale instead... this is a quick reply, hope it makes sense. Greg Sent from my phone On Mon, 18 Oct 2021, 8:01 pm Yishay Weiss, <[email protected]> wrote: > 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? > > > > > > > > > >
