Yes, but someone already did that 6 months ago: http://bugs.adobe.com/jira/browse/FP-1678
No one from Adobe bothered to reply or comment on it, though. As a side note, this is something that I really dislike about Adobe's bug-fixing process (though I don't say this is a bug, but rather a possible improvement) and it's very common if you take a look at jira. I understand that they have lots of request and limited resources. They naturally have to set priorities and though this seems easy to fix, I might be wrong and often things looks easier from the outside. Yet, it's that hard to say "this is low priority", "we'll fix it in the next player", "we will not implement this", etc ? I mean, I don't expect them to fix every reported problem right away, but at least give some kind of feedback so the people that actually take the time to register / login / investigate a problem or bug and report it don't feel like they're wasting time talking to a brick wall. Cheers Juan Pablo Califano 2009/8/8 Muzak <[email protected]> > The bad part, as I said, is that only Adobe can fix this. >> >> So, until that happens (if it happens someday...), I just do a cast to >> DisplayObject on the argument at call time and carry on. >> > > You can always file an enhancement request. > https://bugs.adobe.com/ > > regards, Muzak > > ----- Original Message ----- From: "Juan Pablo Califano" < > [email protected]> > To: "Flash Coders List" <[email protected]> > Sent: Saturday, August 08, 2009 7:39 PM > Subject: Re: [Flashcoders] Interface for displayObjects > > > Hi, >> >> I've had the same problem and couldn't find a real solution. >> >> The simplest thing to do, for me, was just using the as operator: >> >> var obj:ISomeInterface = new ConcreteObject(); >> >> container.addChild(obj as DisplayObject); >> >> I like that it doesn't require an extra variable and it doesn't clutter >> your >> code too badly. >> >> The only real solution, I think, it's on Adobe's hands, since >> DisplayObject >> is a concrete class defined natively by the player (well, sort of, at >> runtime it behaves like an abstract class since you can't create an >> instance >> with new ...). >> >> The cool part is that the change should be simple and backward compatible. >> Just provide an IDisplayObject interface and have DisplayObject implent >> it. >> Then change method signatures in the dispay list API to require >> IDisplayObject instead of DisplayObject. In your code, your interface can >> extend IDisplayObject, and that should solve the problem: >> >> interface ISomeInterface extends IDisplayObject >> >> class ConcreteObject extends Sprite implements ISomeInterface >> >> The bad part, as I said, is that only Adobe can fix this. >> >> So, until that happens (if it happens someday...), I just do a cast to >> DisplayObject on the argument at call time and carry on. >> >> Cheers >> Juan Pablo Califano >> >> > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
