incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <olegsivo...@gmail.com>
Subject Re: [gosh] Compiler choice [was Goshhawk language choices and more]
Date Mon, 20 Feb 2012 17:00:55 GMT
I was actually under impression that Adobe will be committing code to the
compiler and / or framework developed here - that was at least my
understanding of the last whitepaper posted by Adobe, or am I
misunderstanding it? Maybe the word "support" isn't the best choice though.

In my experience, the mx_internal namespace was used often for the purposes
such as to cover the weak points in design. For instance, have you tried to
implement some sort of collection-view interface and extended Proxy, you
would've known that the framework code insists on the objects inside the
collection have mx_internal:uid or even mx_internal_uid property :) I think
that the problem of not documenting things could've been solved by @private
ASDoc meta (and it was indeed used all over the place) and it won't be
particularly difficult to have that sort of comment / annotation in HaXe
source code to show that the API is experimental. So, I think that this is
a non-issue.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message