>>Why is it unsafe actually? >Ignore this. I think I understand why.
For the sake of others who may not It's unsafe because a) even native js code that 'works' could break other royale code - there is no compile time checking relative to the actionscript code that is nearby. This is however also true if you were to use eval code. or b) it may simply be invalid javascript, which probably we will get to hear about from GCC. This is potentially 'better'/'safer' than eval because you don't get to hear about that until runtime when you use eval. and perhaps other reasons I have not thought of... On another level, I have seen similar features to this in other cross-target languages. They are usually discouraged for general use, and the function naming here is part of the way I am including that message here. On Wed, Jan 12, 2022 at 8:59 PM Yishay Weiss <yishayj...@hotmail.com> wrote: > Ignore this. I think I understand why. > > From: Yishay Weiss<mailto:yishayj...@hotmail.com> > Sent: Wednesday, January 12, 2022 9:57 AM > To: dev@royale.apache.org<mailto:dev@royale.apache.org> > Subject: RE: jsUnsafeNativeInline > > Why is it unsafe actually? Because > > From: Greg Dove<mailto:greg.d...@gmail.com> > Sent: Wednesday, January 12, 2022 3:40 AM > To: Apache Royale Development<mailto:dev@royale.apache.org> > Subject: jsUnsafeNativeInline > > Just a quick note to let you know about a new feature. One you probably > don't want to use very often at all. It is a combination of latest compiler > updates and Language swc JS update. > > I added it to avoid a low level use of eval inside Language.as, which was > there in the first place to do some very low level native js stuff and > break a bunch of actionscript rules for the hidden internal implementation > of synthType (which you don't need to know about, except that it helps > mimic some classes like int, uint and Vector etc). > > I had to make the change because I encountered an issue with > Content-Security-Policy in a client application, which was causing the > browser to not run any eval code. > Now, I think there is only usage in a couple of places, most notably on an > as-needed basis in ExternalInterface implementation I think (I will see if > I can use this to avoid it in ExternalInterface also before too long). > > Anyway... you probably won't use it, but it does let you use native js > injected inline. > > The one thing I can think of that is helpful is this: > COMPILE::JS{ > jsUnsafeNativeInline('debugger'); > } > > because for some reason, I can't see 'debugger' in the typedefs. > > Anyway that can help you set a breakpoint that works in the js-release (as > well as js-debug) code. Which can sometimes be helpful when figuring out > release build issues. Outside of that I guess it probably won't be super > helpful. > > >
