[GitHub] [royale-asjs] greg-dove edited a comment on issue #641: Fix PAYG violations and code debt

[GitBox <gi...@apache.org>]

greg-dove edited a comment on issue #641: Fix PAYG violations and code debt
URL: https://github.com/apache/royale-asjs/issues/641#issuecomment-569537423
 
 
   Thanks for the reflection data info. I am not sure why that is happening. it seems odd, especially if it is being selectively included for certain classes and not others. I will look into it.
   
   class names are required for some binding cases and in all cases for reflection. I am not sure if there are other use cases.
   
   For @royalesuppressexport I only added compiler support for that earlier this year. 
   The beginnings of docs are here, (definitely needs attention):
   [https://apache.github.io/royale-docs/create-an-application/optimizations/doc-comment-directives.html#miscellaneous](https://apache.github.io/royale-docs/create-an-application/optimizations/doc-comment-directives.html#miscellaneous)
   That does not mention use at class level, because it was originally introduced as class member level only (where it also continues to work). Using it at class level makes the whole class un-reflectable and removes all exports. I have used that in a couple of places so far (and in the imminent swf graphics support).
   
   However I think it would be a mistake to apply use of it too liberally because doing so makes assumptions that we know more about what users want than they do.
   I think classes with only static utility functions would be 'low risk' for using this, but even so we cannot be certain that someone somewhere will never want to use them with regular reflection support from the framework, hence they are not 'no risk'. Wherever I have used it so far I (hope I) have documented the class as being unreflectable in javascript.
   As a general comment, I would personally favour more approaches for optimization that are opt-in by users rather than imposed on them.
   For reflection data in general, one option I already suggested earlier for this could be the categorization of code (via bit flags) to allow for selective removal from release builds via goog define. Static utility classes could be one type of categorization here. Framework/Non-framework could be another, with plenty more scope for categories (the set of categories being something for collective review I think). Technically I believe this is possible, and would mean users could elect to retain reflection data for only the parts that are needed (within reason: categorization has its own 'generalizations', by definition). And by default it could allow all categories. Whether it is the best way to do this, I am not sure. But this feature could also (for example) be introduced post 1.0 because I don't think this is high priority from users (based on asking them what's important - although my discussion focus has always been on migrating legacy Flex apps with the various people I have been talking to during past several months - migrating apps is still the best opportunity for growth IMO).

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services