On Sun, Jul 28, 2013 at 11:24 PM, Alex Harui <aha...@adobe.com> wrote:
> > > On 7/28/13 2:20 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: > >> > >> At this point, I'm liking flags better, but I'm still not decided. > >> > >> > >Sounds like a good compromise. Although I am not sure if it solves the > >issue of index management. I guess it would look like this: > >addElementAt(o:Object, index:int, flags:uint) > > > >Ex. > >container.addElementAt(obj, 3, CONTAINER_ELEMENT_TYPES.CHROME_ELEMENT); > >container.addElementAt(obj, 6, CONTAINER_ELEMENT_TYPES.CHILD_ELEMENT); > I was thinking the flags go on the object, not on the API, so it is just > addElementAt(o:Object, index:int); > > Every component will have a property for the flags, either a bit mask or > an object with strings. AddElementAt checks the flags and puts chrome > elsewhere. > Ah, makes sense. > > > > >The user still needs to keep track of the index length chrome elements and > >regular elements. > I don't think I'm understanding this. > If I want to add an element as a chrome, I will need to know the number of elements already added as chrome so that I can figure out the index that I want. Same for elements added as normal childs. There are two different indices because internally we are adding to two different containers (this.addChild() vs. actualParent.addChild()) How do we make this clear to the API user? I guess I am worried about making it easier for folks to trip over themselves. Two API calls with same signatures means it is reasonably obvious to the user even if there are chances for runtime errors. Two API calls with different signatures (IChrome vs. DisplayObject) means that any problems will be caught at compile time. > > >I like how the spark Panel has a controlBarContent property to which we > >can > >assign an array display objects directly. Similarly, we could have a > >Container.chromeElements object to which chrome elements could be added > >directly? > That's also a possibility. The main drawback to that is that Arrays are > not watchable in AS or JS, so you have to implement some sort of ArrayList > per instance which sounds too heavy. > I agree, this approach is a bit heavier, but might give us more reliable APIs. > > > > > >> -Alex > >> > >> > >
