It's really all about the design. It very much depends on what you're trying to use the interfaces to achieve.
If you're finding that you constantly need to downcast the interfaces to concrete objects then either your design isn't one that's suited to interfaces, or you're using them in the wrong way. Why is it that you're ending up having to call functions that aren't defined in the interface? Don't get me wrong - there can be extremely good reasons for this. But if it's happening throughout your code, then you've got a design problem and should maybe think about refactoring something. The same would be true of using ordinary superclasses rather than interfaces, incidentally - it's the constant downcasting that shows there's something up... Cheers, Ian On 6/15/06, Mark Lapasa <[EMAIL PROTECTED]> wrote:
Thanks EKA and JC for your answers. I -kinda- knew that was the answer but I wanted to know if there was another way. Casting/trantyping an abstract object down into one of a concrete type seems like to me very self-defeating to use abstractions as a data type. I might as well say var tmp:ConcreteClass = new ConcreteClass(); tmp.bar(); as JC has mentioned and forget about the low-coupling flexibility of using interfaces. I imagined the inital route I wanted to go ought to work at run-time but the compiler is not forgiving.
_______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
