1. Helps autocomplete2. Helps the compiler catch errors in its tracks, so you don't get runtime errors
I can't explain any better than what I've done! Sorry I can't be more help ben Omar Fouad wrote:
Ok, but how does an Interface help in this case? On Tue, Aug 26, 2008 at 4:10 AM, ben gomez farrell <[EMAIL PROTECTED]>wrote:Hmmmm, not sure what you're stumbling on - of course all this stuff is a mouthful, so my point is I could've been unclear in ANYTHING! Anyway - so typecasting variables - Lets say you have a variable...in AS3 the compiler needs to know what type of variable it is. so var x = 4 will just throw a compiler error if I recall correctly. What you need to to is: var x:Number = 4; This way the compiler knows what you're type casting your variable as. Now - say you don't know what type of object to cast your variable as.... This may come up if you are throwing a bunch of different types of objects or classes into a variable with the same code. So you could do var x:Object = whatever or var x:* = whatever. The problem here is when you assume do really generic things like that, IF there is a bug, you'll only find out about it at runtime. Like lets say you had two classes MObjectA.as and MyObjectB.as. Let's also say I'm somewhere in my code, where I need to throw them into the same variable one after another (it can happen, in like a for loop when you have a bunch of different objects in an array, and you're looping through) Anyway, I want to do: var x = new MyObjectA(); x.doSomething(); x.doSomethingElse(); x = new MyObjectB(); x.doSomething(); x.doSomethingElse(); But that's not quite right....You need to typecast x - but if it's the same class, you COULD either generically type it with an object: var x:Object or a wildcard var x:* But lets say you call a method that isn't there (or you mispelled your method name). With such generic typecasting, it'll just compile, and you won't catch this error until runtime. The compiler will just say "Well, it's generic, it could be anything - so I'll just compile it, and hope the programmer knows what they're doing!". But, if MyObjectA and MyObjectB have a common set of methods, like doSomething() and doSomethingElse(), I could create and interface with these two methods, and make MyObject A and B implement these two methods. Then I can type x as: var x:IMyObject = new MyObjectA or B() Now if I'm using something like Flex builder, I'll get full autocomplete when i start using my variable. If I misspell a method, or try to use one that isn't there my COMPILER will complain before I even run it. So typecasting is just a little more organized and lets you know whats going on, and interfaces help if you have the above situation. And I don't know if i'd call it MORE OOP - i'd say it makes use of more spiffy things that OOP has to offer, but I don't think there really needs to be a contest on who's programming is more OOP, whatever works for the situation works for the situation. It's like saying my backyard is more outdoors than your because you have a tree, but I have a tree and a bush and a flower garden. We both have backyards, but I have more things in mine. That's my opinion anyway! good luck! ben Omar Fouad wrote:Wow... Thanks! Ben, would you please explain the last part that talks about type casting? Another Question: I've also read that using interface is more OOP. How? Cordially On Tue, Aug 26, 2008 at 2:23 AM, ben gomez farrell <[EMAIL PROTECTED]wrote:Hey I don't know what kind of development teams your working with, but I've found that on small one off projects done with a small team, they aren't that important. It's more of a big team, long term project, lotsa code type thing. You can absolutely go with never using them, but it's a nice thing to learn, and starts to get useful with AS3 type checking. So, an interface file is like a contract you are setting up with your code. An interface (and you can see the syntax in your books), consists of public variables and functions and their return types. These functions don't do anything in the interface itself, that is they don't run. Where your interfaces get used is when you have a class that "implements" one of your interfaces. So lets say you have MyClass extends MySuperClass implements IMyInterface. (by convention interface files start with I....etc, but of course you don't have to) So, for your project to even compile (when you implement an interface), you'd better be damn sure that your "MyClass" has all the functions and variables YOU defined in IMyInterface It seems limiting, but, on a large team, you might have a dozen developers creating a hundred or so classes that are all supposed to plugin somewhere in your main project. If you create an interface, and make it known that all developers must implement your interface, you can be sure that your dozen developers and your hundred classes are going to have the methods that YOU need to work in your project. And then if you make a large scale change to your project - you can just change the interface - maybe add another method to it that you need for additional functionality. If your dozen developers update to the new interface file, all their code won't compile anymore - and they'll have to update to your new methods before they get a compile! So it's handy on large teams. I've also found it handy for typecasting in AS3. Sometimes I might have 2 classes that do sort of the same thing, but not quite. Maybe I have a mix of several similar (but not identical) objects in an array, and I want to loop through. So for example: list = [ myClassA, myClassB, myClassC, myClassA, myClassB, myClassC, myClassA, myClassB, myClassC ]; Now I loop through my objects, and I want to assign them to like a temporary variable and perform an action on them. So.... var temp = list[c]; But what do you type temp...you could do var temp:* = list[c] And you could put anything you wanted in the variable. But we have type casting in AS3 for a reason! You could create an interface full of the common methods and variables uses by myClass A,B and C, make those classes implement your interface, and then do your typecasting as this: var temp:IMyClasss = list[c]; Then you aren't using the wildcard to type your object AND you'll get auto-complete for code, and compile time checking of anything you're trying to do to your class that isn't supported. Hope this helps! ben Omar Fouad wrote:This could seem weird... But what the hell is an interface!!!???????? I've read lots of books and posts without getting the answer. I bought "Essential AS3" to read about interfaces and he says that helps for multi inheritance. In other places I read that it is a "deal" to ensure that a class has some methods and so on. But what is the real benefit that I can come out with using interfaces???? Maybe that is stupidity or I am not smart enough to get the concept but believe me... its is been two years now!! Please Help!!!_______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders_______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
