OK. So I’ll just use public for now and put @private in the ASDocs. We’ll figure it all out later.
On Nov 12, 2015, at 7:10 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 11/12/15, 8:52 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> Here’s where I am (and why I’m asking): >> >> I figured out how to use Document and Element as the underlying structure >> for JS XML. But to use them correctly, I need to manipulate the internal >> structure of one XML object from another. >> >> One example: in ActionScript XML you can call appendChild to move the >> child of one XML object to another. In JS, appendChild only works if both >> elements belong to the same document. So if the XML object belongs to a >> different document, I need to call removeChild on its parent (why in the >> world does ActionScript XML not have removeChild()???) in addition to >> importNode(). Also, for appendChild() I need to get the delegate of the >> new child to call appendChild() on that. >> >> So there need to be public methods which expose some of the internals, >> but they really should not be full public APIs. >> >> Any ideas on a good way to structure this? > > There are going to be plenty of public APIs that we don’t want to expose > to certain sets of consumers. But to me, the advantages of abstracting > implementations with Interfaces outweighs the effort to “fake” namespaces > in the JS side. That’s why I’m considering a more elaborate ASDoc viewer > that can filter public APIs based on tags. IMO, that would give us the > usability benefits of namespaces. I’ve seen plenty of folks hack into > mx_internal APIs anyway, so why not just make them all public and make it > easier to document which ones are provided for application developers vs > implementation details? > > I figure we can decide on some @developer or @application tag (and maybe > more) that the doc viewer could filter on. Maybe even @common and > @advanced. > > -Alex
