You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Harbs <ha...@gmail.com> on 2018/03/04 10:24:47 UTC

Understanding ROYALE_CLASS_INFO

ROYALE_CLASS_INFO is something which is output for every class and not optimized away by the Google Closure Compiler. I’m trying to understand why and whether there’s some way this can be optimized.

1. What prevents the compiler from removing this property? It’s not @exported.
2. Why is it being prevented from being optimized away? I see it’s used in 10 different files. It’s obviously being assumed to exist for various reflection tasks. Is part of the problem that the compiler might not be able to infer the type of an instance?
3. Why is “names” an array? ActionScript does not support multiple inheritance.
4. Would it be less code to use some kind of ClassInfo object or utility function rather than use object literals for every single class? It feels like yes.

Harbs

Re: Understanding ROYALE_CLASS_INFO

Posted by Greg Dove <gr...@gmail.com>.
From memory, Harbs (and I have been absent for a while so it might not be
accurate), it is important for runtime type checks against interfaces,
maybe other things, but yes it is part of the support for reflection too
(the more detailed reflection data is the extra weight there).

btw, I do hope to get active again within the next month or so. I was
working on constants propagation (for primitive types -
numeric/bool/string) and had made some progress on that before I had to
give my attention to other things.



On Sun, Mar 4, 2018 at 11:24 PM, Harbs <ha...@gmail.com> wrote:

> ROYALE_CLASS_INFO is something which is output for every class and not
> optimized away by the Google Closure Compiler. I’m trying to understand why
> and whether there’s some way this can be optimized.
>
> 1. What prevents the compiler from removing this property? It’s not
> @exported.
> 2. Why is it being prevented from being optimized away? I see it’s used in
> 10 different files. It’s obviously being assumed to exist for various
> reflection tasks. Is part of the problem that the compiler might not be
> able to infer the type of an instance?
> 3. Why is “names” an array? ActionScript does not support multiple
> inheritance.
> 4. Would it be less code to use some kind of ClassInfo object or utility
> function rather than use object literals for every single class? It feels
> like yes.
>
> Harbs

Re: Understanding ROYALE_CLASS_INFO

Posted by Alex Harui <ah...@adobe.com.INVALID>.

On 3/4/18, 2:24 AM, "Harbs" <ha...@gmail.com> wrote:

>ROYALE_CLASS_INFO is something which is output for every class and not
>optimized away by the Google Closure Compiler. I’m trying to understand
>why and whether there’s some way this can be optimized.
>
>1. What prevents the compiler from removing this property? It’s not
>@exported.

Almost every Royale App uses Language.as and SimpleCSSValuesImpl, both of
which reference ROYALE_CLASS_INFO

>2. Why is it being prevented from being optimized away? I see it’s used
>in 10 different files. It’s obviously being assumed to exist for various
>reflection tasks. Is part of the problem that the compiler might not be
>able to infer the type of an instance?

It isn't about type inferences as far as the runtime is concerned it is,
it is about testing the AS type of something for "is" and "as" and for our
extended Type Selectors.

>3. Why is “names” an array? ActionScript does not support multiple
>inheritance.

Not sure.  I didn't design this structure, but I think it may be intended
for internal classes, although I don't think we are currently using it for
that.

>4. Would it be less code to use some kind of ClassInfo object or utility
>function rather than use object literals for every single class? It feels
>like yes.

If you want to try to redesign the implementation, feel free, but IMO, it
isn't a high priority.

-Alex

>
>Harbs