Re: [Flashcoders] A Question that I've been asking for years!!
I have most of these books and for me the ones that help the most are... http://www.amazon.com/Essential-ActionScript-3-0/dp/0596526946 http://www.amazon.com/Advanced-ActionScript-3-Design-Patterns/dp/0321426568 http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612 It's so easy to get confused by the jargon. An interface is just what is in-between - like the handle on a saucepan. The interface tells you know what the methods are. That's it. So then you know how to get hold of it, talk to it, call it, pick it up. And if something else has the same set of methods (same interface) then either one of them can be passed into some generic method (polymorphic - many forms, same interface) that's expecting an item with certain features. By the way, I am eternally grateful to you all for the thousands of comments of yours that enlighten me. Thank you! John (mutator) Ron Wheeler wrote: Second the recommendation. Great book - applies to ActionScript easily. Ron Steven Loe wrote: Check out "Head First Design Pattens" (oreilly). It's an easy to comprehend book on patterns and software design goodness. The book examples are in Java, so if you can read AS3 you'll be able to read sample code. It a great resource to learn not only what interfaces are, but why and when you want to use them. IMO its made EAS3 *much* easier going. Moock's interface / pattern explanations make much more sense after spending some time with Head First Design Pattens. -Steven Loe 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!!! -- 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 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 ___ 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
RE: [Flashcoders] A Question that I've been asking for years!!
Read books will help to understand the concept, let's try an example: Let's say you built a flash library and one of your class (ex: Main class) needs another proper class to be instantiated (like a Config class). Main class constructor: Public function Main(config:IConfig):void { } IConfig is an interface because you want to be sure the guys are going to pass a class as a parameter that implementing IConfig: public class MyConfig implements IConfig and then instantiate: var main:Main = new Main(new MyConfig()); Why doing that? You want to be sure that you will have the functions required in the Config class passed as a parameter to make it work correctly. The interface describe it: public interface IConfig { function init():void; function get myPropertyNeeded():String; function myFunctionNeeded():String; } If they pass a Config class that miss one of these functions/properties, you won't be able to compile as you need to pass a proper IConfig implementation. Sorry if my example is not really good, I'm not an OOP wizard, neither a teacher :) but I hope it helps. Romu www.soundstep.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ron Wheeler Sent: 11 September 2008 13:36 To: Flash Coders List Subject: Re: [Flashcoders] A Question that I've been asking for years!! Second the recommendation. Great book - applies to ActionScript easily. Ron Steven Loe wrote: > Check out "Head First Design Pattens" (oreilly). It's an easy to comprehend book on patterns and software design goodness. The book examples are in Java, so if you can read AS3 you'll be able to read sample code. > > It a great resource to learn not only what interfaces are, but why and when you want to use them. IMO its made EAS3 *much* easier going. Moock's interface / pattern explanations make much more sense after spending some time with Head First Design Pattens. > > > -Steven Loe > > > > >>> 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!!! >>> >>> -- >>> 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 >>> 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 >> > > > > ___ > 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
RE: [Flashcoders] A Question that I've been asking for years!!
>> Second the recommendation. >>Great book - applies to ActionScript easily. Wow. This really is the thread that keeps mutating won't die! Shoot me now! :) Check the dates people! LOL. Jason Merrill Bank of America Instructional Technology & Media Join the Bank of America Flash Platform Developer Community Are you a Bank of America associate interested in innovative learning ideas and technologies? Check out our internal Innovative Learning Blog & subscribe. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] A Question that I've been asking for years!!
Second the recommendation. Great book - applies to ActionScript easily. Ron Steven Loe wrote: Check out "Head First Design Pattens" (oreilly). It's an easy to comprehend book on patterns and software design goodness. The book examples are in Java, so if you can read AS3 you'll be able to read sample code. It a great resource to learn not only what interfaces are, but why and when you want to use them. IMO its made EAS3 *much* easier going. Moock's interface / pattern explanations make much more sense after spending some time with Head First Design Pattens. -Steven Loe 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!!! -- 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 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 ___ 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
Re: [Flashcoders] A Question that I've been asking for years ...
On Sat, Sep 6, 2008 at 9:37 AM, S0 F1 <[EMAIL PROTECTED]> wrote: > Interfaces allow 'Polymorphism'. Many say this is OOP's greatest > contribution to computer science. > > Any thoughts on this? What you've described above has no need for interfaces. That's just standard OOP polymorphism based on inheritance of concrete objects. Interfaces are actually more useful for objects which aren't necessarily related via inheritance. It's worth reading back through this long (and quite old, as Jason points out) thread - there are a lot of good answers in it. Ian ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] A Question that I've been asking for years ...
Interfaces allow 'Polymorphism'. Many say this is OOP's greatest contribution to computer science. Polymorphism occurs when a superclass stands in for a subclass. This is extremely useful when you don't know exactly what type of class (usually a concrete class) is needed at a specific spot within your code. Example: class Vehicle extends Sprite - class Car extends Vehicle class Boat extends Vehicle class Plane extends Vehicle Using the above, you can declare an attribute as type Vehicle in any spot where you don't know exactly which of the 3 vehicle types the application will be operating on. There needs to be a way (in my opinion) to define a type, it's methods/properties and whether these methods/properties are public or private. Also, you should be able to define concrete implementation within these methods. As I understand it, the closest you can get to what I've described above, is an abstract class which implements an interface, and methods within the abstract class throw an error - to make sure that a class extending the abstract overwrites said methods. Any thoughts on this? ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] A Question that I've been asking for years!!
What I mean is, this same THREAD! :) Jason Merrill Bank of America Enterprise Technology & Global Risk L&LD Instructional Technology & Media Join the Bank of America Flash Platform Developer Community Are you a Bank of America associate interested in innovative learning ideas and technologies? Check out our internal Innovative Learning Blog & subscribe. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Merrill, Jason Sent: Friday, September 05, 2008 2:28 PM To: Flash Coders List Subject: RE: [Flashcoders] A Question that I've been asking for years!! Déjà vu - wasn't this question asked and thoroughly answered like over a month ago? Jason Merrill Bank of America Enterprise Technology & Global Risk L&LD Instructional Technology & Media Join the Bank of America Flash Platform Developer Community Are you a Bank of America associate interested in innovative learning ideas and technologies? Check out our internal Innovative Learning Blog & subscribe. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Loe Sent: Friday, September 05, 2008 2:13 PM To: Flash Coders List Subject: RE: [Flashcoders] A Question that I've been asking for years!! Check out "Head First Design Pattens" (oreilly). It's an easy to comprehend book on patterns and software design goodness. The book examples are in Java, so if you can read AS3 you'll be able to read sample code. It a great resource to learn not only what interfaces are, but why and when you want to use them. IMO its made EAS3 *much* easier going. Moock's interface / pattern explanations make much more sense after spending some time with Head First Design Pattens. -Steven Loe > > 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!!! > > > > -- > > 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 > > 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 ___ 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
Re: [Flashcoders] A Question that I've been asking for years!!
Or this book, which is specifically concerning design patterns in AS: http://oreilly.com/catalog/9780596528461/ Alternatively, 'Friends of Ed' also make GREAT books, and they have several on the subject of AS, OOP & design patterns. They are more like 'classes in a book' that you can later reference, whereas Oreilly is more like a proper reference bible. Both formats have merit. Steven Loe wrote: Check out "Head First Design Pattens" (oreilly). It's an easy to comprehend book on patterns and software design goodness. The book examples are in Java, so if you can read AS3 you'll be able to read sample code. It a great resource to learn not only what interfaces are, but why and when you want to use them. IMO its made EAS3 *much* easier going. Moock's interface / pattern explanations make much more sense after spending some time with Head First Design Pattens. -Steven Loe 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!!! -- 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 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 ___ 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
RE: [Flashcoders] A Question that I've been asking for years!!
Déjà vu - wasn't this question asked and thoroughly answered like over a month ago? Jason Merrill Bank of America Enterprise Technology & Global Risk L&LD Instructional Technology & Media Join the Bank of America Flash Platform Developer Community Are you a Bank of America associate interested in innovative learning ideas and technologies? Check out our internal Innovative Learning Blog & subscribe. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Loe Sent: Friday, September 05, 2008 2:13 PM To: Flash Coders List Subject: RE: [Flashcoders] A Question that I've been asking for years!! Check out "Head First Design Pattens" (oreilly). It's an easy to comprehend book on patterns and software design goodness. The book examples are in Java, so if you can read AS3 you'll be able to read sample code. It a great resource to learn not only what interfaces are, but why and when you want to use them. IMO its made EAS3 *much* easier going. Moock's interface / pattern explanations make much more sense after spending some time with Head First Design Pattens. -Steven Loe > > 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!!! > > > > -- > > 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 > > 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 ___ 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
RE: [Flashcoders] A Question that I've been asking for years!!
Check out "Head First Design Pattens" (oreilly). It's an easy to comprehend book on patterns and software design goodness. The book examples are in Java, so if you can read AS3 you'll be able to read sample code. It a great resource to learn not only what interfaces are, but why and when you want to use them. IMO its made EAS3 *much* easier going. Moock's interface / pattern explanations make much more sense after spending some time with Head First Design Pattens. -Steven Loe > > 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!!! > > > > -- > > 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 > > 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 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] A Question that I've been asking for years!!
There is one usecase that most Flash developers will come across. Lets say we have a loader.swf in which the main (or base) class is Loader.as. Loader.as loads main.swf, main.swf has as main (or base) class Main.as. Loader.as needs to give a signal to the loaded main.swf and tries to type the instance on the stage as Main. This way, Loader.as will makes sure the file that is loaded is who he expects it to be (namely Main.as). The above situation poses a problem. If Loader.as references Main.as, Main.as will be compiled into loader.swf as well. In most cases this will result in a loader.swf that is of the same size as main.swf. In order to fix this we need to make use of an interface. The Main.as will implement the interface and Loader.as will type Main.as not as Main, but as the interface. This way only the interface will be compiled into the loader and not the implementation (or Main.as). While this solves the problem described earlier it also gives some extra benefits. The loader is suddenly reusable. It no longer depends on a specific implementation of any class. It will accept all classes that implement the interface. I hope this usecase adds anything to the discussion. Greetz Erik On Tue, Aug 26, 2008 at 4:32 AM, ben gomez farrell <[EMAIL PROTECTED]>wrote: > Yah, maybe the word isn't "contract" but a "contract with loopholes". > Anyway, it does a good job of getting intention across, regardless, across > a broad set of code. But yah, i can see the value in it, and I can see that > its a little extra effort that might not be worth it. I'm still more in the > stage where I try to apply it to things to see if it's useful. I'm not sure > if it's helped so far, but it hasn't hurt. > > ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] A Question that I've been asking for years!!
On Wed, Aug 27, 2008 at 7:30 AM, Mark Winterhalder <[EMAIL PROTECTED]> wrote: > Say you write a class that draws a pretty chart. It has a method that > reads a series of values by repeatedly calling readInt(), which is > guaranteed by IDataInput, and draws that data. If your method takes a > ByteArray, it works fine for preloaded or locally stored data. If it > takes a Socket, it works for a live data stream off the net. But if it > takes an IDataInput, it can do both, without any additional effort -- > you pass it a /data source/, and decide at runtime where you get it > from. Mark wins the clear explanation award. :-D > You don't have to work in a team to appreciate interfaces. I agree. Other places that I find them useful are: - Writing some sort of plugin-based system, where app A wants to talk to app B; both are compiled in isolation (and possibly by different people or teams). Agreeing on and writing a simple interface means that both apps can be compiled against that interface, and it really doesn't matter about the internals of either app. For example, a portal site that loads games; the portal might offer an interface to the loaded games to be able to record their scores. If written to an interface (rather than compiled against potentially changing more complex code), games written for portal v1 will work for portal v3 and beyond. Or maybe even for other people's portals. :-) - The same applies to an app that's broken into modules; if the main app contains all the 'real' code and the submodules are written to talk to interfaces, then the bulk of the code is only compiled (and loaded) once. (You can achieve the same thing with externs or exclude lists, but I find it easier with interfaces.) - As a marker or tag. (This is used a lot in Java). If you want to mark somehow that a class is 'special' - the typical example would be if you want to mark a class as being safely serialisable without additional code - you have it implement an interface with no methods e.g. public interface ISerializable {}. If your class implements that interface, then the test 'if (yourObj is ISerializable)' comes out true, and your code can make decisions based on that. (This is how things were done before metadata - in AS3, I'd do it with metadata.) - Where inheritance really doesn't work. For example, what if you want to offer a common logging facility - say a log() method - to loaded classes within your application. You could pass them an instance of your main application, MyApp, which defines the log() method. But what if you reuse that code in another app, MyApp2? Then you'd either need to recompile, or find a common base class. Fine, create a common base class - CommonApp, which defines the log() method, and have MyApp and MyApp2 both derive from that. But what if those two apps are unrelated and can't inherit from a common user-defined base class - for example, one is a WindowedApplication (for use in AIR) and the other is a plain old Application? They can't share a common base... so what do you pass to your classes that want a logger and where do you define log()? The answer is to define a common interface, e.g. IApp that supports log(), and pass that instead. That is probably far less clear than Mark's example. :-) Ian ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] A Question that I've been asking for years!!
I think Hans (and Claus ;) explained it very well, so just to reiterate, sometimes it's just useful to specify methods instead of ancestors as an argument type. For an example, have a look at flash.utils.IDataInput. It's implemented by ByteArray, Socket and URLStream. Obviously, a ByteArray and a Socket don't have much in common, in terms of how they do their thing, but they both are used to read (and write) data. Often, that's all you need to know. Say you write a class that draws a pretty chart. It has a method that reads a series of values by repeatedly calling readInt(), which is guaranteed by IDataInput, and draws that data. If your method takes a ByteArray, it works fine for preloaded or locally stored data. If it takes a Socket, it works for a live data stream off the net. But if it takes an IDataInput, it can do both, without any additional effort -- you pass it a /data source/, and decide at runtime where you get it from. Another example could be some code that calculates the distance between two coordinates. It takes two objects that both have an x and a y property. You'd use essentially the same code to calculate the distance between Points or Sprites, but you'd have to write two methods: There is no ICoordinate interface (requiring an x and y property) that they could implement. If there was, you'd only need one method to do it, and on top of that it could also calculate the distance between a Point and a Sprite, as a free bonus. (Calculating a distance may seem like a trivial example, but it could also be, say, a quad tree for hit testing.) To solve Hans' adapter problem, you'd use the IContinentalOutlet interface, which is required by his continental player to work. The various adapters he collected during his travels all look different and even are from different vendors. But they all implement the IContinentalOutlet interface, /how/ they do it doesn't matter. You don't have to work in a team to appreciate interfaces. They simply make code more flexible, that's a good thing, use them where appropriate (I'd even go as far and say "when in doubt, use an interface"). Mark On Tue, Aug 26, 2008 at 12:44 PM, Hans Wichman <[EMAIL PROTECTED]> wrote: > Hi, > > interfaces are pretty simple in reality and they are everywhere. > Imagine every wall outlet looked different, and not only different, but that > in order to use them, you had to remove the outlet first, take a look at the > wiring and then bolt it back on with you finally knowing how to use it. > > Would we accept that as a fact of life? No sir. > So what would we do? > > We'd come up with a brilliant plan to take over the world, and it involves > agreeing on what a wall outlet looks like and what we expect it to do. So no > matter the device I want to plug in, as long as my device agrees with the > interface it has been offered, it's good to go. > > Will it work without problems everywhere and always? Nah try to plug in your > dutch mp3player in the uk, no go, but within a certain context they can work > wonders. > > hth :) > JC > > On Tue, Aug 26, 2008 at 9:49 AM, Cor <[EMAIL PROTECTED]> wrote: > >> Very good, Claus, >> >> Do you have a visual of this... LOL >> >> Regards >> Cor >> >> -Original Message----- >> From: [EMAIL PROTECTED] [mailto: >> [EMAIL PROTECTED] On Behalf Of Claus Wahlers >> Sent: dinsdag 26 augustus 2008 9:42 >> To: Flash Coders List >> Subject: Re: [Flashcoders] A Question that I've been asking for years!! >> >> An example is worth a thousand words. >> >> public interface IBounce { >>function bounce():void; >> } >> >> public class Balls implements IBounce { >>public function bounce():void { } >> } >> >> public class Boobs implements IBounce { >>public function bounce():void { } >> } >> >> var balls:Balls = new Balls(); >> var boobs:Boobs = new Boobs(); >> doSomethingWith(balls); >> doSomethingWith(boobs); >> >> function doSomethingWith(bouncyObject:IBounce):void { >>bouncyObject.bounce(); >> } >> >> Cheers, >> Claus. >> >> 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 &
RE: [Flashcoders] A Question that I've been asking for years!!
Nice explaination Hans, BTW to use my dutch MP3-player there is an adapter (interface) for every country. But maybe it would be better if the Dutch took over the world LOL Cor Yeah... Dutch!! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hans Wichman Sent: dinsdag 26 augustus 2008 12:45 To: Flash Coders List Subject: Re: [Flashcoders] A Question that I've been asking for years!! Hi, interfaces are pretty simple in reality and they are everywhere. Imagine every wall outlet looked different, and not only different, but that in order to use them, you had to remove the outlet first, take a look at the wiring and then bolt it back on with you finally knowing how to use it. Would we accept that as a fact of life? No sir. So what would we do? We'd come up with a brilliant plan to take over the world, and it involves agreeing on what a wall outlet looks like and what we expect it to do. So no matter the device I want to plug in, as long as my device agrees with the interface it has been offered, it's good to go. Will it work without problems everywhere and always? Nah try to plug in your dutch mp3player in the uk, no go, but within a certain context they can work wonders. hth :) JC On Tue, Aug 26, 2008 at 9:49 AM, Cor <[EMAIL PROTECTED]> wrote: > Very good, Claus, > > Do you have a visual of this... LOL > > Regards > Cor > > -Original Message- > From: [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] On Behalf Of Claus Wahlers > Sent: dinsdag 26 augustus 2008 9:42 > To: Flash Coders List > Subject: Re: [Flashcoders] A Question that I've been asking for years!! > > An example is worth a thousand words. > > public interface IBounce { >function bounce():void; > } > > public class Balls implements IBounce { >public function bounce():void { } > } > > public class Boobs implements IBounce { >public function bounce():void { } > } > > var balls:Balls = new Balls(); > var boobs:Boobs = new Boobs(); > doSomethingWith(balls); > doSomethingWith(boobs); > > function doSomethingWith(bouncyObject:IBounce):void { >bouncyObject.bounce(); > } > > Cheers, > Claus. > > 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 ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] A Question that I've been asking for years!!
Hi, interfaces are pretty simple in reality and they are everywhere. Imagine every wall outlet looked different, and not only different, but that in order to use them, you had to remove the outlet first, take a look at the wiring and then bolt it back on with you finally knowing how to use it. Would we accept that as a fact of life? No sir. So what would we do? We'd come up with a brilliant plan to take over the world, and it involves agreeing on what a wall outlet looks like and what we expect it to do. So no matter the device I want to plug in, as long as my device agrees with the interface it has been offered, it's good to go. Will it work without problems everywhere and always? Nah try to plug in your dutch mp3player in the uk, no go, but within a certain context they can work wonders. hth :) JC On Tue, Aug 26, 2008 at 9:49 AM, Cor <[EMAIL PROTECTED]> wrote: > Very good, Claus, > > Do you have a visual of this... LOL > > Regards > Cor > > -Original Message- > From: [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] On Behalf Of Claus Wahlers > Sent: dinsdag 26 augustus 2008 9:42 > To: Flash Coders List > Subject: Re: [Flashcoders] A Question that I've been asking for years!! > > An example is worth a thousand words. > > public interface IBounce { >function bounce():void; > } > > public class Balls implements IBounce { >public function bounce():void { } > } > > public class Boobs implements IBounce { >public function bounce():void { } > } > > var balls:Balls = new Balls(); > var boobs:Boobs = new Boobs(); > doSomethingWith(balls); > doSomethingWith(boobs); > > function doSomethingWith(bouncyObject:IBounce):void { >bouncyObject.bounce(); > } > > Cheers, > Claus. > > 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
RE: [Flashcoders] A Question that I've been asking for years!!
Very good, Claus, Do you have a visual of this... LOL Regards Cor -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Wahlers Sent: dinsdag 26 augustus 2008 9:42 To: Flash Coders List Subject: Re: [Flashcoders] A Question that I've been asking for years!! An example is worth a thousand words. public interface IBounce { function bounce():void; } public class Balls implements IBounce { public function bounce():void { } } public class Boobs implements IBounce { public function bounce():void { } } var balls:Balls = new Balls(); var boobs:Boobs = new Boobs(); doSomethingWith(balls); doSomethingWith(boobs); function doSomethingWith(bouncyObject:IBounce):void { bouncyObject.bounce(); } Cheers, Claus. 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
Re: [Flashcoders] A Question that I've been asking for years!!
An example is worth a thousand words. public interface IBounce { function bounce():void; } public class Balls implements IBounce { public function bounce():void { } } public class Boobs implements IBounce { public function bounce():void { } } var balls:Balls = new Balls(); var boobs:Boobs = new Boobs(); doSomethingWith(balls); doSomethingWith(boobs); function doSomethingWith(bouncyObject:IBounce):void { bouncyObject.bounce(); } Cheers, Claus. 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
RE: [Flashcoders] A Question that I've been asking for years!!
An interface is used to control that the classes who extends the interface mandatory have at least the same methods and properties. So when you work in a team of programmers/developers everyone using/extending this class MUST confirm all these methods and properties. HTH Cor ;-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Omar Fouad Sent: dinsdag 26 augustus 2008 0:40 To: Flash Coders List Subject: [Flashcoders] A Question that I've been asking for years!! 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!!! -- 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 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
Re: [Flashcoders] A Question that I've been asking for years!!
u I just don't know how else to explain! If using multiple similar classes it can tie them together in a way that: 1. Helps autocomplete 2. 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: H, 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 rightYou 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 Ietc, 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 deve
Re: [Flashcoders] A Question that I've been asking for years!!
On Aug 25, 2008, at 10:07 PM, Juan Pablo Califano wrote: This strikes me as the typical gratiutous bashing of some product just because it's made by MS. But perhaps you could elaborate a bit more on the idea... Nah, it doesn't have anything to do with Microsoft. I don't have anything against them personally. I just think VB is weird, and interfaces in VB are even weirder. A coworker in the past did a lot of that stuff and I paid a modicum of attention to the code. I do think VB is slightly cracked out though - but that has nothing to do with MS. :) - jb ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] A Question that I've been asking for years!!
interface. An interface is not used directly, it's, like Ben mentioned, a "contractual agreement" that a class will contain certain things. It's useful in a team coding environment. Interfaces traditionally start with a capital letter "I" as in IUserView.as. Jason Merrill Bank of America Enterprise Technology & Global Risk L&LD Instructional Technology & Media Join the Bank of America Flash Platform Developer Community Are you a Bank of America associate interested in innovative learning ideas and technologies? Check out our internal Innovative Learning Blog & subscribe. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Sampson Sent: Monday, August 25, 2008 7:01 PM To: Flash Coders List Subject: Re: [Flashcoders] A Question that I've been asking for years!! I'm certainly no expert but as I understand it, an interface is a class that is only good for inheriting, never instantiating. For example - if you were going to write two classes - Baseball and Softball, you would want a parent class Ball. However, you won't ever instantiate a Ball, you'll always use one of the subclasses. Furthermore, Baseball and Softball both have similar properties (pitch, circumference, weight, etc) but those functions are implemented differently between the two. So instead of making a Ball class and overriding all the methods both times, you would make an Interface that they both implement. You haven't written any code in the interface, just defined that all Ball objects will have a pitch method, and a circumference and weight, and the implementation is up to them. So that's all well and good but the real power is that you can use Ball as a data type later to refer to either type: myBall:Ball = new Softball(). I hope that helps - On Mon, Aug 25, 2008 at 3:39 PM, Omar Fouad <[EMAIL PROTECTED]> 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!!! -- 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 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 ___ 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
Re: [Flashcoders] A Question that I've been asking for years!!
>>> If you are using a cracked out language like VB, they might be marginally useful in weird circumstances that are, in my opinion, probably poor programming choices in the first place. They serve little purpose in general, and even less in actionscript. >>> This strikes me as the typical gratiutous bashing of some product just because it's made by MS. But perhaps you could elaborate a bit more on the idea... Cheers Juan Pablo Califano 2008/8/25, Jon Bradley <[EMAIL PROTECTED]>: > > > On Aug 25, 2008, at 6:39 PM, Omar Fouad wrote: > > 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 >> > > If you are using a cracked out language like VB, they might be marginally > useful in weird circumstances that are, in my opinion, probably poor > programming choices in the first place. > > They serve little purpose in general, and even less in actionscript. > > My 0.01 is that you certainly need to know them, because you might run into > some libraries that use them. > > My remaining 0.01 is that you need to know them so you can get rid of them > from anyone else's code library. > > :P > > - jon > ___ > 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
Re: [Flashcoders] A Question that I've been asking for years!!
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: > H, 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 rightYou 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 >>> Ietc, >>> 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
Re: [Flashcoders] A Question that I've been asking for years!!
merica Flash Platform Developer Community > > Are you a Bank of America associate interested in innovative learning > ideas and technologies? > Check out our internal Innovative Learning Blog & subscribe. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rob > Sampson > Sent: Monday, August 25, 2008 7:01 PM > To: Flash Coders List > Subject: Re: [Flashcoders] A Question that I've been asking for years!! > > I'm certainly no expert but as I understand it, an interface is a class > that > is only good for inheriting, never instantiating. > For example - if you were going to write two classes - Baseball and > Softball, you would want a parent class Ball. However, you won't ever > instantiate a Ball, you'll always use one of the subclasses. > Furthermore, > Baseball and Softball both have similar properties (pitch, > circumference, > weight, etc) but those functions are implemented differently between the > two. So instead of making a Ball class and overriding all the methods > both > times, you would make an Interface that they both implement. You haven't > written any code in the interface, just defined that all Ball objects > will > have a pitch method, and a circumference and weight, and the > implementation > is up to them. > > So that's all well and good but the real power is that you can use Ball > as a > data type later to refer to either type: myBall:Ball = new Softball(). > > I hope that helps - > > > On Mon, Aug 25, 2008 at 3:39 PM, Omar Fouad <[EMAIL PROTECTED]> > 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!!! > > > > -- > > 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 > > 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 > ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] A Question that I've been asking for years!!
On Aug 25, 2008, at 6:39 PM, Omar Fouad wrote: 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 If you are using a cracked out language like VB, they might be marginally useful in weird circumstances that are, in my opinion, probably poor programming choices in the first place. They serve little purpose in general, and even less in actionscript. My 0.01 is that you certainly need to know them, because you might run into some libraries that use them. My remaining 0.01 is that you need to know them so you can get rid of them from anyone else's code library. :P - jon ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] A Question that I've been asking for years!!
H, 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 rightYou 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 Ietc, 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 ha
RE: [Flashcoders] A Question that I've been asking for years!!
Interfaces have nothing to do with inheritance (at least not directly) as I understand them. Interfaces are special classes that simply define what other classes must define. A class that implements an interface has to define the methods and properties defined in an interface. An interface is not used directly, it's, like Ben mentioned, a "contractual agreement" that a class will contain certain things. It's useful in a team coding environment. Interfaces traditionally start with a capital letter "I" as in IUserView.as. Jason Merrill Bank of America Enterprise Technology & Global Risk L&LD Instructional Technology & Media Join the Bank of America Flash Platform Developer Community Are you a Bank of America associate interested in innovative learning ideas and technologies? Check out our internal Innovative Learning Blog & subscribe. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Sampson Sent: Monday, August 25, 2008 7:01 PM To: Flash Coders List Subject: Re: [Flashcoders] A Question that I've been asking for years!! I'm certainly no expert but as I understand it, an interface is a class that is only good for inheriting, never instantiating. For example - if you were going to write two classes - Baseball and Softball, you would want a parent class Ball. However, you won't ever instantiate a Ball, you'll always use one of the subclasses. Furthermore, Baseball and Softball both have similar properties (pitch, circumference, weight, etc) but those functions are implemented differently between the two. So instead of making a Ball class and overriding all the methods both times, you would make an Interface that they both implement. You haven't written any code in the interface, just defined that all Ball objects will have a pitch method, and a circumference and weight, and the implementation is up to them. So that's all well and good but the real power is that you can use Ball as a data type later to refer to either type: myBall:Ball = new Softball(). I hope that helps - On Mon, Aug 25, 2008 at 3:39 PM, Omar Fouad <[EMAIL PROTECTED]> 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!!! > > -- > 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 > 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
Re: [Flashcoders] A Question that I've been asking for years!!
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 Ietc, > 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 > -- 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 Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] A Question that I've been asking for years!!
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 Ietc, 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
Re: [Flashcoders] A Question that I've been asking for years!!
I'm certainly no expert but as I understand it, an interface is a class that is only good for inheriting, never instantiating. For example - if you were going to write two classes - Baseball and Softball, you would want a parent class Ball. However, you won't ever instantiate a Ball, you'll always use one of the subclasses. Furthermore, Baseball and Softball both have similar properties (pitch, circumference, weight, etc) but those functions are implemented differently between the two. So instead of making a Ball class and overriding all the methods both times, you would make an Interface that they both implement. You haven't written any code in the interface, just defined that all Ball objects will have a pitch method, and a circumference and weight, and the implementation is up to them. So that's all well and good but the real power is that you can use Ball as a data type later to refer to either type: myBall:Ball = new Softball(). I hope that helps - On Mon, Aug 25, 2008 at 3:39 PM, Omar Fouad <[EMAIL PROTECTED]> 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!!! > > -- > 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 > 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