greg-dove commented on issue #78: Assign to Boolean variable does not convert 
to true or false, breaking loose comparison with ==
URL: https://github.com/apache/royale-compiler/issues/78#issuecomment-461681225
 
 
   For things like this it might also be useful to consider what has been done
   or is being done elsewhere.
   I think with React it is becoming more popular to use Typescript for type
   definitions now. But it also has a way to 'type' properties, with support
   for runtime type checking using 'proptypes'. You can get a bit of a sense
   of that here:
   https://reactjs.org/docs/typechecking-with-proptypes.html
   
   It does the type of thing that you described above as runtime type checking
   with the expected overhead, but this is only present in the dev/debug
   build. It is completely absent from the release build.
   
   I'm not saying we prioritize something like this, as I assume it could be
   time-consuming to get right, but something like this, if introduced in the
   future, could provide the same type of type safety as the player in debug
   builds, allowing for runtime checking, but have zero cost for the release
   build where it is absent. Maybe something like this could even diagnose
   issues with boolean coercion at runtime in the debug build and identify
   specific cases where initialization to false was required.
   
   Anyway... for me the 'actionscript compliance' is more about
   predictability/reliability (as a language), and I consider this ahead of
   performance, and I don't think I would be alone in that. But I am also sure
   there is a spectrum of opinion/views.
   In the end I think if something seems to not work the way it should (based
   on established rules for the language) then it can be perceived to be
   unpredictable or unreliable.
   
   I'll leave it there... I just wanted to mention the possibility of this
   type of runtime thing as debug-only. For now, as you said, I think we have
   a good decision on this topic.
   
   
   On Fri, Feb 8, 2019 at 4:00 PM aharui <[email protected]> wrote:
   
   > Sounds like we have agreement on this particular topic.
   >
   > I do want to post some thoughts about "actionscript compliance". IMO, it
   > may never truly be practical to fully emulate the ActionScript runtime in
   > the output and I think there are bigger fish to fry right now than to try
   > to fully emulate everything the runtime can do. So to me, the argument for
   > compliance or consistency is not a clear winner. The cost of the
   > implementation in terms of code size and performance and committer time
   > should be weighed against the likelihood of occurrences. Sometimes, we
   > should encourage or even require our early adopters to change their code.
   >
   > The particular case I'm thinking of is the generic property read or write.
   > Right now, if you have code like:
   >
   > function foo(bar:Object):void {
   > bar.baz = 2;
   >
   > The compiler/transpiler will generate:
   >
   > bar.baz = 2;
   >
   > But that will not work in the browser if bar is XML or Proxy. It will work
   > in the Flash runtime. I would not be in favor of replacing all property
   > accesses with a call to some utility function that checks the type and
   > makes the right call like the Flash runtime does. IOW, to have some thing
   > like:
   >
   > function Language.write(o:Object, prop:String, value:*):void
   > {
   >    if (o is Proxy)
   >      o.setProperty(prop, value);
   >    else if (o is XML) {
   >      if (prop.charAt(0) == "@")
   >         o.setAttribute(prop, value);
   >      else
   >        o.replace(prop, value);
   >    }
   >    else
   >      o[prop] = value;
   > }
   >
   > And then generate:
   >
   > Language.write(bar, "bar", 2);
   >
   > I wouldn't want our default output to look like that and run each property
   > read and write through another function call. I don't think that would be
   > the right first impression to give people. Folks migrating are currently
   > required to rewrite the code and inject the tests they need or
   > strongly-type "bar" if they always know what it will be. And that might
   > need to be "good enough" for now.
   >
   > —
   > You are receiving this because you commented.
   > Reply to this email directly, view it on GitHub
   > 
<https://github.com/apache/royale-compiler/issues/78#issuecomment-461674685>,
   > or mute the thread
   > 
<https://github.com/notifications/unsubscribe-auth/AEW31huXaA_myUt8p3-ZgdOme3T_VeFfks5vLOhHgaJpZM4amRoa>
   > .
   >
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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