> But to me, the advantages of abstracting implementations with Interfaces outweighs the effort to “fake” namespaces in the JS side.
This is essentially a namespace anyway. The interface is the namespace, if you make the framework interface centric, then casting to the concrete type is the public namesapce for developers extending it not clients using it. I think in past AS dev, interface were to underused for a good API. I know in my apps using Feathers and IOC, I have say IModel and my ModelImpl. ModelImpl is injected as IModel, so my API is clean, but if there is any time I need to experiment with some new API I just ModelImpl(model).foo(). I get that encapsulation still, I know this is elementary but it is really powerful but it has to be created that way from the ground up and enforced as a design pattern. Mike On Thu, Nov 12, 2015 at 1:50 PM, Harbs <harbs.li...@gmail.com> wrote: > 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 > >
