Re: [GitHub] greg-dove commented on issue #78: Assign to Boolean variable does not convert to true or false, breaking loose comparison with ==

[Greg Dove <gr...@gmail.com>]

Actually I guess it's not quite like that. Because that actually has logic
that would require it to stay in the release output anyway. But maybe the
more general type checking for runtime assignments to types etc could be
implemented...


On Fri, Feb 8, 2019 at 4:46 PM GitBox <gi...@apache.org> wrote:

> 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 <no...@github.com> 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:
> users@infra.apache.org
>
>
> With regards,
> Apache Git Services
>