In Actionscript 3 I can't declare vars in Interfaces. I don't get it. I know i can work this around by defining getters and setters, but what if i just want a simple public property? I usually use getters and setters if there is something to do when i set or get a property, but what if i just want to store a value?
A:
I'm not an actioscript programming, but interfaces (in java for example) are meant to define behavior not state, so intrerfaces in jave simply declare methods that the class implemeting the interface needs to define. Properties (or instance variable) are not in general necessary to define behavior and there are disallowed in interfaces.
ennuikiller
2009-07-23 20:40:18
Properties are not the same as instance variables.
Pavel Minaev
2009-07-23 21:03:07
+1 on that ... in principle ... because this is not really valid for AS3 ... there is a distinction between properties (provided by accessors) and variables ... from the outside this is completely transparent, being IDENTICAL on syntactical level ... but effectively property access means a call and variable access does not ... interfaces may declary property accessors, but not variables ... this is not 100% consistent nor reasonable ... but that's life, i guess ... :)
back2dos
2009-07-23 21:05:44
A:
You can put it like this: interfaces exist because in your language you can't inherit from multiple abstract base classes. If AS3 would have allowed you to do that, it would probably not have 'interfaces', but 'pure abstract classses'.
In other words, having properties implementation in your interface would lead to name clashes and from there to other multiple inheritance problems (diamond).
However, having just a getter or a setter with no implementation should work.
public interface I { function get A():int; }
(I don't have the AS3 compiler at hand)
Vlagged
2009-07-23 20:55:37
your answer is the right solution ... allthough i totally disagree about what you are saying about interfaces ... inheritance is inherently bad ... :D ... no, seriously ... the point of inheritance is CODE REUSE ... but usually it is misused to accomplish what interfaces are designed for: describing an objects role ... golden rule: classes define implementation, interfaces behaviour ... don't use classes to require behaviour ... don't write someMethod(someParam:SomeClass), write someMethod(someParam:SomeInterface) ... this is much more flexible/extensible and cleaner ...
back2dos
2009-07-23 21:13:15
I tried to avoid making a statement about multiple inheritance being good or bad:) Only pointed out that if you have properties implementation in these 'interfaces', it would require a mechanism similar to multiple inheritance when the compiler finds 2 interfaces with the same property defined.
Vlagged
2009-07-23 21:34:57
+1
A:
A property in most programming languages that support them have two distinct parts that you need to separate:
- The external definition (ie. what is the property name, what is its type, what meta-data is associated with it)
- The internal definition (ie. what does it do in order to store and/or retrieve its value)
An interface is only ever concerned about the external definition. The interface stipulates a contract by saying "all classes that implement this interface will have this property with this specific name, and this specific type". However, what it does when you access it, that's left to that specific class.
That's also the reason why you cannot define variables in interfaces (in all the languages I know of). Doing that would add an implementation detail that the class would have to implement. Basically it would say "any class that implements this interface will have a publicly available variable with this name and type". A variable, however, does not have an internal definition, so there's no way for the class to add behaviour, for instance to provide a calculation when read from, or a security check when written to.
Lasse V. Karlsen
2009-07-23 21:31:27