I didn't realize you could just instantiate an embedded image and get a Bitmap object, so I assumed titleIcon was a custom 'factory' class, sort of the way item renderers are used. My mistake, and you can safely ignore my previous message.
On 2021/10/18 09:41:17, Greg Dove <[email protected]> wrote: > 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? > > > > > > > > > > > > > > >
