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!!
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!!
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!!
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 ...
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 ...
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. snip 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!!
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!!
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 LLD 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!!
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!!
What I mean is, this same THREAD! :) Jason Merrill Bank of America Enterprise Technology Global Risk LLD 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 LLD 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!!
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!!
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
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!!
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!!
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!!
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!!
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!!
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!!
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!!
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
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!!
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!!
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 LLD 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!!
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 have to
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!!
Focusing on the contract part always seemed to me a bit misleading about
what interfaces are, from a developer point of view. I mean, I understand
that using an interface will make the compiler force you to implement some
method, with some given signature, and I see the value in it, especially
force larger projects, with various developers. Nevertheless, what always
bugged me about this it will force you to implement this method approach
is that, well, it does but it depends on how you define implemeting. One
can arguably claim that this is not a real implementation:
public function doSomeStuff(someArg:int):SomeType {
return null;
}
An still, it's perfectly legal, will compile without a hitch, and will of
course bomb out at runtime if you happent to use that return value for
anything useful.
In think being sure that a method will exist at runtime is a problem that
should concern the people who write a compiler and a runtime, but hardly the
coder who develops using that compiler and targeting that runtime. I mean,
following the contract approach, I agreee interfaces are a good language
feature, but I feel like they're often presented as a silver bullet.
On the other hand, interfaces are very useful to make some object to be an
instance of multiple types in a language that doesn't allows multiple
inheritance. And that could be powerful in certain sitautions.
Maybe one example will make the point more clear than some abstract
rambling.
Some time ago, I had to build a kind of engine for some simple, 2D games.
Basically, a main character, some enemies with a rather modest IA, some
generic collision detection, the ability to shoot and being shot, and so
on.
I had some managers to handle different aspects like collisions, moving
objects, chasing some other objects, etc. The thing was, some kind of
enemy could have the ability to move and get shot, but maybe not shooting.
Some other enemy would just move; another one would just shot but not move;
a wall had to be hitable, but wouldn't move or shoot, etc, etc. And the
main character could have its own set of features.
So, the problem was that an object had to be passed to different methods and
I wanted to keep things typed (i.e. not using Object everywhere): the
checkCollision() method would receive two hitable objects, for instance,
or the move() method would be called on a movable object. My first
approach was using inheritance but it looked ugly and smelled bad. It was
clear that it would be a mess having some enemy class arbitrarily descending
from a Shooter class, which in turn descended from a Movable class, which in
turn inherited from a Hitable class, ad nauseam.
I asked some advice from a co-worker and while discusing it, it ocurred to
us that we could use interfaces to make an object hitable, movable, a
shooter, and so forth. Of course we would lack the specific
implementation, but the overall result was much more clean, flexible and
mantainable than forcing some weird inheritance relationship. Perhaps having
real multiple would have saved some duplicated code, since much of the
code to move some objects was identical and we weren't extending base
classes but implementing interfaces in each movable object. But reading
about it, I found that some more knowleadgeble people than me argue that
having real multiple inheritance would add not only a perhaps useful
feature, but a whole new set of problems, so interfaces are a way to keeping
things simpler. So probably not having it is not a bad desing decision -- I
also tend to favour shallower hierarchies whenever possible, so keeping
things as simple as you can is an approach that easily fits my mindset.
So, hopefuly, this could be a modest example of how using interfaces relate
to having an object share a number of different types -- which, admitedly,
is not necessarily and technically the same thing as multiple inheritance,
but I think is conceptually close.
Cheers
Juan Pablo Califano
2008/8/25, Merrill, Jason [EMAIL PROTECTED]:
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 LLD
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:
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 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
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!!
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.
Juan Pablo Califano wrote:
Focusing on the contract part always seemed to me a bit misleading about
what interfaces are, from a developer point of view. I mean, I understand
that using an interface will make the compiler force you to implement some
method, with some given signature, and I see the value in it, especially
force larger projects, with various developers. Nevertheless, what always
bugged me about this it will force you to implement this method approach
is that, well, it does but it depends on how you define implemeting. One
can arguably claim that this is not a real implementation:
public function doSomeStuff(someArg:int):SomeType {
return null;
}
An still, it's perfectly legal, will compile without a hitch, and will of
course bomb out at runtime if you happent to use that return value for
anything useful.
In think being sure that a method will exist at runtime is a problem that
should concern the people who write a compiler and a runtime, but hardly the
coder who develops using that compiler and targeting that runtime. I mean,
following the contract approach, I agreee interfaces are a good language
feature, but I feel like they're often presented as a silver bullet.
On the other hand, interfaces are very useful to make some object to be an
instance of multiple types in a language that doesn't allows multiple
inheritance. And that could be powerful in certain sitautions.
Maybe one example will make the point more clear than some abstract
rambling.
Some time ago, I had to build a kind of engine for some simple, 2D games.
Basically, a main character, some enemies with a rather modest IA, some
generic collision detection, the ability to shoot and being shot, and so
on.
I had some managers to handle different aspects like collisions, moving
objects, chasing some other objects, etc. The thing was, some kind of
enemy could have the ability to move and get shot, but maybe not shooting.
Some other enemy would just move; another one would just shot but not move;
a wall had to be hitable, but wouldn't move or shoot, etc, etc. And the
main character could have its own set of features.
So, the problem was that an object had to be passed to different methods and
I wanted to keep things typed (i.e. not using Object everywhere): the
checkCollision() method would receive two hitable objects, for instance,
or the move() method would be called on a movable object. My first
approach was using inheritance but it looked ugly and smelled bad. It was
clear that it would be a mess having some enemy class arbitrarily descending
from a Shooter class, which in turn descended from a Movable class, which in
turn inherited from a Hitable class, ad nauseam.
I asked some advice from a co-worker and while discusing it, it ocurred to
us that we could use interfaces to make an object hitable, movable, a
shooter, and so forth. Of course we would lack the specific
implementation, but the overall result was much more clean, flexible and
mantainable than forcing some weird inheritance relationship. Perhaps having
real multiple would have saved some duplicated code, since much of the
code to move some objects was identical and we weren't extending base
classes but implementing interfaces in each movable object. But reading
about it, I found that some more knowleadgeble people than me argue that
having real multiple inheritance would add not only a perhaps useful
feature, but a whole new set of problems, so interfaces are a way to keeping
things simpler. So probably not having it is not a bad desing decision -- I
also tend to favour shallower hierarchies whenever possible, so keeping
things as simple as you can is an approach that easily fits my mindset.
So, hopefuly, this could be a modest example of how using interfaces relate
to having an object share a number of different types -- which, admitedly,
is not necessarily and technically the same thing as multiple inheritance,
but I think is conceptually close.
Cheers
Juan Pablo Califano
2008/8/25, Merrill, Jason [EMAIL PROTECTED]:
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.
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!!
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 developers
