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 >>> [email protected] >>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>> >>> >>> >> >> >> >> >> > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > -- Omar M. Fouad - Digital Emotions http://www.omarfouad.net This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
