On 11/12/15, 3:16 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>While working on XML, I have a situation where I’d like to use an >internal namespace for some functions (like mx_internal and tlf_internal >scattered around the classic Flex SDK). I do not see internal used in >FlexJS. Was this a conscious decision, or nothing came up where internal >was desirable? Any preferences on an internal name if I do use one? Well, I wouldn’t make a rule against it, but here are some reasons why I’m trying not to do it in FlexJS: 1) No such thing as namespaces in JS. 2) We can fake them by decorating names of methods, but I find that a bit messy. 3) Only public functions can be in interfaces. I want FlexJS to use lots of interfaces so that implementations can be swapped out, unit tested with mocks, etc. 4) At Adobe, we used mx_internal for APIs we weren’t sure we wanted to document. In FlexJS, because we supposedly will have swappable implementations, it doesn’t matter if you have an API you don’t like, you can always swap in an implementation with a better API. The use of interfaces has exposed a lot more APIs as public APIs. I am pondering the idea of a doc viewer. Instead of a pile of HTML pages like ASDoc is now, an AIR app that is a bit smarter and can handle different categories of public APIs. So far, it appears that there are public APIs most likely to be used by app developers, and other public APIs used by the various beads to talk to each other. None of this is set in stone, so alternative viewpoints are most welcome. -Alex
