greg-dove commented on issue #641: Fix PAYG violations and code debt
URL: https://github.com/apache/royale-asjs/issues/641#issuecomment-569545910
 
 
   > Additionally (possibly related), I don't understand why it's necessary to 
include methods in reflection data.
   
   Having information about what methods are available, their associated 
metadata (if any), what parameters they take and what is expected to be 
returned by calling them is one very common use of reflection (probably on any 
platform). This is true of instance methods or static methods (although static 
methods may be less commonly used). The two Unit testing setups are one 
example, Crux is another. While parameters are not so relevant in unit testing 
(because test methods don't have any), for example, the other aspects just 
described are important (for both static and instance methods). 
   Regardless of whether you use the reflection classes or not, exporting is 
necessary for string based access of public methods, whether they are static or 
instance.
   
   The question again is whether an app uses a feature that needs that or not. 
I addressing that IMO is again something I think the user should have control 
over.
   
   Assuming we are resigned to having a dependency on GCL, I think moving to 
'@export' annotations may have been a mistake, longer term.
   
   If (for example) a user decided there was never a need for exported output, 
this too could be delineated in all classes with a goog define, so users could 
opt to avoid it. Reflection is probably the main use, but I think things like 
constant bindings need it too.
   You might remember a thread where I mentioned this type of thing in the past 
(being able to 'switch' options like default initializers etc) without having 
to recompile swcs. I think you and Josh liked the idea, but not everyone did. 
The same thing could be applied here:
   //exports section near bottom of class output
   if (Build.INCLUDE_EXPORTS || (some expression for reflection category match) 
) { //goog.defines
   
   //output all exports explicitly here (via goog.exportProperty etc instead of 
via @export annotations)
   
   }
   
   I personally think that type of approach where 'things work' by default, but 
people can switch them off easily with low effort is the better solution longer 
term, and also starts to make more use of GCC for what it is supposed to be 
good at. I can't however prioritize it at the moment.

----------------------------------------------------------------
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:
[email protected]


With regards,
Apache Git Services

Reply via email to