Re: [Flashcoders] A Question that I've been asking for years!!

2008-09-11 Thread Ron Wheeler

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!!

2008-09-11 Thread Merrill, Jason
 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!!

2008-09-11 Thread Romuald Quantin
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!!

2008-09-11 Thread John McCormack

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 ...

2008-09-06 Thread S0 F1
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 ...

2008-09-06 Thread Ian Thomas
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!!

2008-09-05 Thread Steven Loe
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!!

2008-09-05 Thread Merrill, Jason
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!!

2008-09-05 Thread sebastian

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!!

2008-09-05 Thread Merrill, Jason
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!!

2008-09-02 Thread EECOLOR
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!!

2008-08-27 Thread Mark Winterhalder
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!!

2008-08-27 Thread Ian Thomas
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!!

2008-08-26 Thread Cor
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!!

2008-08-26 Thread Claus Wahlers

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!!

2008-08-26 Thread Cor
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!!

2008-08-26 Thread Hans Wichman
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!!

2008-08-26 Thread Cor
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


[Flashcoders] A Question that I've been asking for years!!

2008-08-25 Thread Omar Fouad
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


Re: [Flashcoders] A Question that I've been asking for years!!

2008-08-25 Thread Rob Sampson
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!!

2008-08-25 Thread ben gomez farrell
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!!

2008-08-25 Thread Omar Fouad
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!!

2008-08-25 Thread Merrill, Jason
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!!

2008-08-25 Thread ben gomez farrell
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!!

2008-08-25 Thread Jon Bradley


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!!

2008-08-25 Thread Juan Pablo Califano
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!!

2008-08-25 Thread Omar Fouad
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!!

2008-08-25 Thread Juan Pablo Califano

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!!

2008-08-25 Thread ben gomez farrell
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!!

2008-08-25 Thread Jon Bradley


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!!

2008-08-25 Thread ben gomez farrell
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