greg-dove commented on issue #641: Fix PAYG violations and code debt URL: https://github.com/apache/royale-asjs/issues/641#issuecomment-570118207 The issue with Reflection data being 'held' is fixed and was something GCC related to do with the way I added some new data items at one point (which were not being exported). Maybe it is something that works in a more recent version of GCC. There was no self-referencing or external referencing involved, so I'm not sure why it was treating it as if there was something like that. Either way I was able to avoid it with a refactor of some specific Reflection support data. The original data was set up as a nested part of the original reflection data function/object. The change was to simply add it directly to prototype as extra data fields. Because these are only there to support specific reflection needs they will still be eliminated from apps that use only Reflection functionality that doesn't need this specific data. Anyway, good call Harbs, thanks for drawing attention to this. **slightly OT:** I think there is still scope for future improvements for users of Reflection itself as I mentioned earlier, but IMO this focus ('must be smallest possible') is not what most people think is a priority and so I think it is just something to do 'when I can get to it'. I believe Royale output already compares favorably to other options. Based on actually dealing with credibility challenges when talking to prospective clients, people are most keen to see their business logic work like it did before and following on from that, can be sold on components still needing 'some work' (and possible contributions from them being required to achieve that). Unless we start growing the community very soon I fear it will be too late. That is the most critical thing this year if Royale is to gain some traction and to ultimately have some outcome of success, in my mind. One of the biggest impediments to confidence in choosing Royale is the small number of developers. It's more about the long term ramifications than the short term availability of those of us who (like me) who are available. I believe 1.0 is a starting point for that and it would be great if we could all come to some agreement on that. I might be wrong but I think people generally agree, perhaps with some reservations, or at least don't disagree with the idea. Alongside that it would be good to collaborate on a collective shortlist of what is vital to get there (not what is 'ideal'). I'll bring that up as a topic on dev list soon (feel free to do so yourselves if you want). **another OT:** I would be happy to try to update to latest GCC (in a branch) at some point (again, not something I consider a priority now that the Reflection thing is resolved) but want to check one thing - are we still stuck on Java 7 SDK minimum for everything or can we up the minimum to 8? GCC has 8 as a minimum, and I see in the past that Alex has back-ported some GCC code with the local Config variation work in 7. This could get increasingly more tricky I think with the use of lambda expressions in the more recent GCC code, although I am still learning-as-I-go on this stuff.
---------------------------------------------------------------- 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
