That's exactly what I've came around to solve the problem, I've used "java-like" getters and setters. However it would be more "pretty" and useful if I could use the default AS getters and setters method :)
But I agree with you, it's probably some kind of "bug" related to the fact that I'm using two different namespaces. "Ambiguous error" isn't the best way to describe it since both methods have different signatures and different ways of being accessed: SET: impl.data = "something"; GET: impl.data; I will keep using the workaround for now and keep tracking any developments in this area. Thank you for your replies. Bruno Leite --- In [email protected], "valdhor" <valdhorli...@...> wrote: > > This looks like it may be a bug. I found the following: > > "If a class contains accessor functions with different access control > namespace attributes, (for example, a protected setter and a public getter) > using one of them causes a compile-time-error, for example, Compiler-Error > 1000: Ambiguous reference to myVar". > > Your getter function is in namespace InterfaceA and your setter is in > namespace InterfaceB. > > The workaround is to rename your getter or setter function to avoid the > mismatch. > > So, instead of creating set/get methods, create setData and getData methods. > You will need to call them slightly differently but it does work... > > var impl1:ImplementationClass = new ImplementationClass(); > var implA:InterfaceA = InterfaceA(impl1); > var implB:InterfaceB = InterfaceB(impl1); > > implB.setdata("Something"); > > trace(implA.getdata()); > > > > --- In [email protected], "bmsleite" <bmsleite@> wrote: > > > > Yes, that's indeed one way to do it, but it does not solve the problem. > > Imagine that we have something like the following example (which is exactly > > what's happening in my case): > > > > var b:InterfaceB = this.call.something.thatReturnsAsAnInterfaceB(); > > b.data = "something"; > > > > In this case I cannot assume that the returned instance is from a specific > > implementation (like 'ImplementationClass'), that's the all point of using > > interfaces :P > > Any other ideas? > > > > Bruno Leite > > > > --- In [email protected], "valdhor" <valdhorlists@> wrote: > > > > > > Shouldn't it be... > > > > > > var impl1:ImplementationClass = new ImplementationClass(); > > > var implA:InterfaceA = InterfaceA(impl1); > > > > > > impl1.data = "Something"; > > > trace(implA.data); > > > > > > > > > --- In [email protected], "bmsleite" <bmsleite@> wrote: > > > > > > > > Hi everyone, > > > > > > > > I hope you guys can help me out with this doubt regarding interfaces > > > that extends from other interfaces. > > > > > > > > The scenario is the following: > > > > > > > > ImplementationClass -implements-> InterfaceB -extends-> InterfaceA > > > > > > > > A code example: > > > > > > > > public interface InterfaceA > > > > { > > > > function get data():*; > > > > } > > > > > > > > > > > > public interface InterfaceB extends InterfaceA > > > > { > > > > function set data(value:*):void; > > > > } > > > > > > > > > > > > public class ImplementationClass implements InterfaceB > > > > { > > > > private var _data:*; > > > > > > > > public function Implementation(){} > > > > > > > > public function set data(value:*):void > > > > { > > > > _data = data; > > > > } > > > > > > > > public function get data():* > > > > { > > > > return _data; > > > > } > > > > > > > > } > > > > > > > > Now, the question is, is this possible? If I write something like > > > this: > > > > > > > > var impl:InterfaceB = new ImplementationClass(); > > > > impl.data = "something"; > > > > > > > > Should this be possible? Well, possible I know that it isn't because > > > this gives me an "Ambigous reference to data" error, but isn't this a > > > logical implementation, am I missing something here? > > > > > > > > Probably the cause for this behaviour has to do with the way that > > > getters and setters are implemented in AS3, if that's the case, can > > > anyone explain me, or give me some ideas how this works internally? > > > > > > > > Thank you for your time. > > > > > > > > Bruno Leite > > > > > > > > > >
