Re: [Flashcoders] Interfaces and private methods ...
On Mon, Aug 4, 2008 at 9:37 AM, Ian Thomas <[EMAIL PROTECTED]> wrote: > Why would you want to force implementation of a private class? Private method. Sorry! ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Interfaces and private methods ...
Why would you want to force implementation of a private class?
Or are you actually trying to create an abstract class - and are
trying to ensure that a subclass provides an implementation of an
internal method? (Labelled as 'private' in AS2 or 'protected' in AS3.)
In which case, neither AS2 nor AS3 have built-in support for abstract
classes, which is a little annoying! The easiest way to achieve a
similar result is to write a default implementation in the parent
class (which the child class is supposed to override) and throw an
error inside it.
e.g. (in AS3)
protected function doSomething():void
{
throw new Error("You should have overridden this!");
}
If that's not your problem/what you're trying to achieve, what _are_
you trying to achieve?
Ian
On Mon, Aug 4, 2008 at 9:13 AM, S0 F1 <[EMAIL PROTECTED]> wrote:
> How can you force a set of classes to define a private method if Interface
> members cannot be declared public, private, protected, or internal?
>
> Create an abstract class with private method(s) that throw an error, unless
> overwritten by subclasses? Is this the only way?
> ___
> 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] Interfaces and private methods ...
Hello, You cannot force a class to implement a private method. And that would be totally useless... The target of an interface is to define a set of methods that are accessible by any classes => private, internal and protected methods are too restricted. What do you want to do ? Regards, Cedric On Mon, Aug 4, 2008 at 10:13 AM, S0 F1 <[EMAIL PROTECTED]> wrote: > How can you force a set of classes to define a private method if Interface > members cannot be declared public, private, protected, or internal? > > Create an abstract class with private method(s) that throw an error, unless > overwritten by subclasses? Is this the only way? > ___ > 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] Interfaces
ah yeah!! How could I forget something like this :D I've been using listeners for similar tasks in this application. Woah. Keeping coding for more than 14 hours daily really comsumes the brain !!! On Wed, Apr 2, 2008 at 3:09 AM, Muzak <[EMAIL PROTECTED]> wrote: > Have the panel with the button dispatch an event to which the parent > (main) listens, The listener then takes care of things (like moving the > panel). > > Interfaces have nothing to do with this. > > regards, > Muzak > > - Original Message - From: "Omar Fouad" <[EMAIL PROTECTED]> > To: "Flash Coders List" > Sent: Wednesday, April 02, 2008 1:58 AM > Subject: Re: [Flashcoders] Interfaces > > > Well, the example in the blog explained it a lot, though it is in > > Actionscript 2.0. > > > > And yes, I wont need Interfaces unless I really feel like I HAVE to use > > them. > > In my project I have some Panels (screens) in the fla Library and each > > one > > of them is linked to a Class (linkage). Each class or Panel extends an > > abstract Class called APanel that extends MovieClip. The APanel Class > > contains some features that I need to be shared to all the other Panels. > > In > > the Main class, I managed how to switch them, based on the application > > flow > > and navigation. I use some navigation buttons that slide them to the > > right > > or to the left of the stage. > > Till here everything worked fine. But at a certain point I found some > > problematic issues. I also need the panels to slide when a certain > > button is > > pressed in one of them. Of course the function I used in the Main Class > > to > > slide the Panels away, wouldn't be available to the other classes unless > > I > > set them to be static, so I could write: > > > > Main.SlideLeft(); > > > > Fine. But to make the function static, I'd put in consideration some > > other > > things like turning some of the Main Class Properties used in the > > function > > to static. And that is a problem because library variables cannot be > > declared static. > > > > So I think that the use of an interface somewhere would solve the > > problem. > > > > ___ > 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] Interfaces
Have the panel with the button dispatch an event to which the parent (main) listens, The listener then takes care of things (like moving the panel). Interfaces have nothing to do with this. regards, Muzak - Original Message - From: "Omar Fouad" <[EMAIL PROTECTED]> To: "Flash Coders List" Sent: Wednesday, April 02, 2008 1:58 AM Subject: Re: [Flashcoders] Interfaces Well, the example in the blog explained it a lot, though it is in Actionscript 2.0. And yes, I wont need Interfaces unless I really feel like I HAVE to use them. In my project I have some Panels (screens) in the fla Library and each one of them is linked to a Class (linkage). Each class or Panel extends an abstract Class called APanel that extends MovieClip. The APanel Class contains some features that I need to be shared to all the other Panels. In the Main class, I managed how to switch them, based on the application flow and navigation. I use some navigation buttons that slide them to the right or to the left of the stage. Till here everything worked fine. But at a certain point I found some problematic issues. I also need the panels to slide when a certain button is pressed in one of them. Of course the function I used in the Main Class to slide the Panels away, wouldn't be available to the other classes unless I set them to be static, so I could write: Main.SlideLeft(); Fine. But to make the function static, I'd put in consideration some other things like turning some of the Main Class Properties used in the function to static. And that is a problem because library variables cannot be declared static. So I think that the use of an interface somewhere would solve the problem. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Interfaces
Well, the example in the blog explained it a lot, though it is in Actionscript 2.0. And yes, I wont need Interfaces unless I really feel like I HAVE to use them. In my project I have some Panels (screens) in the fla Library and each one of them is linked to a Class (linkage). Each class or Panel extends an abstract Class called APanel that extends MovieClip. The APanel Class contains some features that I need to be shared to all the other Panels. In the Main class, I managed how to switch them, based on the application flow and navigation. I use some navigation buttons that slide them to the right or to the left of the stage. Till here everything worked fine. But at a certain point I found some problematic issues. I also need the panels to slide when a certain button is pressed in one of them. Of course the function I used in the Main Class to slide the Panels away, wouldn't be available to the other classes unless I set them to be static, so I could write: Main.SlideLeft(); Fine. But to make the function static, I'd put in consideration some other things like turning some of the Main Class Properties used in the function to static. And that is a problem because library variables cannot be declared static. So I think that the use of an interface somewhere would solve the problem. On Wed, Apr 2, 2008 at 12:24 AM, Muzak <[EMAIL PROTECTED]> wrote: > > > > If you're the only person working on a project, interfaces can be less > > useful unless you know how to use them well. Putting them in just to > > put them in serves no purpose other than bloating your code. But, > > sometimes you need to do that in order to figure them out. > > > > I'd even go as far as saying that if you don't know what they are, you > probably don't need them ;-) > In your typical every day Flex/Flash type of applications they're > (usually) overkill'll. > > You'll see them used in frameworks and microarchitectures, like the Flex > framework, Cairngorm, etc.. > So they're more of an API-thing rather than an RIA-thing (if that makes > sense). > > Have a look at the available flex framework interfaces (they typically > begin with a capital I): > http://livedocs.adobe.com/flex/3/langref/all-index-I.html > > regards, > Muzak > > ___ > 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] Interfaces
If you're the only person working on a project, interfaces can be less useful unless you know how to use them well. Putting them in just to put them in serves no purpose other than bloating your code. But, sometimes you need to do that in order to figure them out. I'd even go as far as saying that if you don't know what they are, you probably don't need them ;-) In your typical every day Flex/Flash type of applications they're (usually) overkill. You'll see them used in frameworks and microarchitectures, like the Flex framework, Cairngorm, etc.. So they're more of an API-thing rather than an RIA-thing (if that makes sense). Have a look at the available flex framework interfaces (they typically begin with a capital I): http://livedocs.adobe.com/flex/3/langref/all-index-I.html regards, Muzak ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Interfaces
On Apr 1, 2008, at 1:19 PM, Omar Fouad wrote: list, I've been reading tons of books and I still can't get the concept of Interfaces. Can someone explain it with an easy example for me? Help will be really appreciated. This guy's example gave me a good foothold. Maybe it will help: http://labs.thesedays.com/2006/12/03/composition-over-inheritance-a-real-life-example/ ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Interfaces
Interfaces can do much more than just help multiple coders stay on track. In Actionscript 3, they can be used to mimic multiple inheritance, decrease file size of loaded swfs, and clarify your own code. Interfaces are simple, but understanding Interfaces and how and when to use them takes a bit more time. You need a firmly established understanding of core OOP concepts like inheritance, abstract/concrete, and factories. Once you fully understand those, the transition into learning how interfaces work will be a lot easier and will pave the way for the "Ah ha!" moment when you actually "get" how they benefit you. If you're the only person working on a project, interfaces can be less useful unless you know how to use them well. Putting them in just to put them in serves no purpose other than bloating your code. But, sometimes you need to do that in order to figure them out. For instance, let's say you have multiple swfs, and some class and its inheritance chain is fairly large when compiled. Rather than import the Abstract class type in the loaded swfs, you can instead import the Interface for the class and your loaded swf won't need to know the inner workings of any class that follows the interface to compile. At runtime, the class will exist because the main movie loaded it, and all the loaded swf needs to know is that if it calls a particular method of an interface, it's guaranteed to be in the class because the class follows that interface. That's just one example of how interfaces can be used. If you want to see some example code for interfaces, install my Gaia Framework, create a new AS3 project, and take a look at the com.gaiaframework.api package. There are interfaces for all of the asset classes, as well as the the main Gaia API. There are more complicated uses for interfaces, such as multiple inheritance, but best to learn the basics before you jump into that aspect. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Interfaces
An interface is used to make sure your code is not tightly coupled. Instead
of saying which class should be given, you say which interface should be
given. This means that a developer has more freedom to implement his own
version of an interface.
Lets say you make a person interface called IPerson. This interface has name
getters and setters:
*public interface IPerson
{
function get name():String;
function set name(name:String):void;
};*
Now you want to fill up a classroom. The only thing needed within the
classroom is the name of a person. To add a person to the classroom you call
the addPerson method. The class:
*public class ClassRoom
{
public function addPerson(person:IPerson):void
{
//do stuff with the person
};
};*
The addPerson method has a person argument typed as IPerson. This means that
I can give any type of instance to this function as long as it implements
the IPerson interface. This interface makes sure that the class given to the
addPerson method has a name getter and setter.
An example of a person:
*class Jack implements IPerson
{
private var _name:String;
public function get name():String
{
return _name;
};
public function set name(name:String):void
{
_name = name;
};
};*
How my class implements the IPerson interface does not matter to the
ClassRoom class. The only thing the ClassRoom class is interested in is the
name getter and setter.
There are a few cases where interfaces come in handy:
- If you want to be able to easialy switch an implementation without
breaking existing code
- If you are using a module and want to call (from the module) a method in
your framework. The framework should be typed as an interface to prevent it
from being compiled into the module.
- If you are not taking care of the actual implementation (another developer
will write this piece of code), you only want a certain method to be
available because you are using this implementation.
- To give freedom to other developers of your code
(mx.core.UIComponentimplements IUIComponent in Flex. And within Flex
everything is typed as
IUIComponent. This means you could write your own version of IUIComponent if
needed.
On a side note. On complex applications I start with writing interfaces for
every part of my application to prevent me from writing actual code and
thinking about the structure. This approach has only personal benefits and
has officially no added value except for the ones named above (in a later
stage).
Greetz Erik
On 4/1/08, Omar Fouad <[EMAIL PROTECTED]> wrote:
>
> Yeah, but I've read that a Class that implements an interface an call
> function from other classes that allready extends other Classes.
> it's like a multiple inheritance. But how can I achieve it?
>
>
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] Interfaces
>>Yeah, but I've read that a Class that implements an interface
>>an call function from other classes that allready extends
>>other Classes.
>>it's like a multiple inheritance. But how can I achieve it?
I don't quite follow what the issue is, but don't confuse inheritance
with implements. Do you mean:
package
{
ClassA extends ClassB implements IClassInterface
{
}
}
Jason Merrill
Bank of America
GT&O and Risk L&LD Solutions Design & Development
eTools & Multimedia
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 GT&O Innovative Learning Blog & subscribe.
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Interfaces
Yeah, but I've read that a Class that implements an interface an call function from other classes that allready extends other Classes. it's like a multiple inheritance. But how can I achieve it? On Tue, Apr 1, 2008 at 10:30 PM, Merrill, Jason < [EMAIL PROTECTED]> wrote: > >>I've been reading tons of books and I still can't get the > >>concept of Interfaces. > > It's actually very very simple. An interface is just a special class > that sets the rules of other classes. So an interface doesn't do > anything in your application, it just helps the coder(s) to make sure > they write certain methods, have certain properties, which return > certain things etc. If a class implements that interface, then the > Flash/Flex whatever compiler will complain if the class is not written > to have certain properties and methods. It's just to help with coding, > especially in team environments, it doesn't actually do anything in your > application. > > Does that make sense? > > Jason Merrill > Bank of America > GT&O and Risk L&LD Solutions Design & Development > eTools & Multimedia > > 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 GT&O Innovative Learning Blog & subscribe. > > > > ___ > 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] Interfaces
>>I've been reading tons of books and I still can't get the >>concept of Interfaces. It's actually very very simple. An interface is just a special class that sets the rules of other classes. So an interface doesn't do anything in your application, it just helps the coder(s) to make sure they write certain methods, have certain properties, which return certain things etc. If a class implements that interface, then the Flash/Flex whatever compiler will complain if the class is not written to have certain properties and methods. It's just to help with coding, especially in team environments, it doesn't actually do anything in your application. Does that make sense? Jason Merrill Bank of America GT&O and Risk L&LD Solutions Design & Development eTools & Multimedia 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 GT&O Innovative Learning Blog & subscribe. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Interfaces: what are the advantages?
Hi Ray, I know what intrinsics are, what they're _supposed_ to be for, and what they're actually used for. :-) It's a matter of personal preference. I don't use them because, as I said earlier, I can do things in other ways. For the purpose I was talking about - seperating code into different .swf files - I'd rather come up with a design that uses interfaces, since interfaces are a part of the language. So far I've had no need for intrinsics. I'm sure if I came up with a need for them, I'd use them. :-) Ian On 10/16/06, Ray Chuan <[EMAIL PROTECTED]> wrote: Hi Ian, an intrinsic is not used only for built-in Flash Player classes/code. You can use it to save yourself some time, since the compiler doesn't compiler the bytecode all again. With intrinsics no bytecode is generated, only type-checking is done. With interfaces bytecode is generated. I'm not saying that interfaces should be done away with and replaced with intrinsics. Interfaces are part of the paradigm, while Intrinsics are, to me, a Flash compiler-only feature for speed purposes, and has no impact whatsoever on your paradigm. (By paradigm i refer to OOP, coding methodology, etc.) ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Interfaces: what are the advantages?
Hi Ian, an intrinsic is not used only for built-in Flash Player classes/code. You can use it to save yourself some time, since the compiler doesn't compiler the bytecode all again. With intrinsics no bytecode is generated, only type-checking is done. With interfaces bytecode is generated. I'm not saying that interfaces should be done away with and replaced with intrinsics. Interfaces are part of the paradigm, while Intrinsics are, to me, a Flash compiler-only feature for speed purposes, and has no impact whatsoever on your paradigm. (By paradigm i refer to OOP, coding methodology, etc.) On 10/14/06, Ian Thomas <[EMAIL PROTECTED]> wrote: Hi Ray, Yes - but why would you, if the language spec already supports interfaces? Using interfaces is a much more 'standard' way (i.e. the same sort of thing you'd do if you were talking to dynamic libraries in other languages). I still see intrinsics as a bit of a hack. "These classes are internal to the Flash Player, honest! Don't look for their implementation". Note the line from the page you link to: "This keyword was not meant for general purpose use..." Still - I'd imagine, like many of these things, in the end it comes down to personal taste. :-) Whatever gets the job done... Ian On 10/14/06, Ray Chuan <[EMAIL PROTECTED]> wrote: > Hi, > can't this be done with intrinsics? > > http://livedocs.macromedia.com/flash/8/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=1879.html ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com -- Cheers, Ray Chuan ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Interfaces: what are the advantages?
On 10/14/06, slangeberg <[EMAIL PROTECTED]> wrote: >Oddly, in AS3 Macrodobe have taken out the facility to mark a constructor as anything else than public I think they're following the Java language closely, which only has public constructors. Hi Scott, No, Java does allow private/protected constructors - see the Java language spec: http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6.1 It's very handy - both for abstract classes (although Java has the abstract keyword, which helps!) and for singletons. Also for classes which should only be generated through factory objects. AS3 is following/defining ECMAScript rather than Java (but admittedly the language is very Java-like). I've no idea why Adobe have chosen to shut off support for non-public constructors. But I've a vague memory of reading somewhere in Labs that it was an oversight and might get put back in again. :-) Ian ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: Re: [Flashcoders] Interfaces: what are the advantages?
On 10/14/06, slangeberg <[EMAIL PROTECTED]> wrote: Ian, > That being the case, I can't quite see how intrinsics apply, as by their nature they include no implementation at all. Ah, good point. I just got excited when I saw that variable in there. It is one step closer to abstract. >Oddly, in AS3 Macrodobe have taken out the facility to mark a constructor as anything else than public I think they're following the Java language closely, which only has public constructors. Java does support private constructors. Using a private constructor is the standard way of creating Singletons in Java just like in AS2. Java also does support abstract classes which neither AS2 or AS3 do. There are some ways to get around this limitation in AS though, but all are pretty much hacks, and the limitation makes it tougher to read the code and to understand the true intention of the programmer. I would love to lobby Adobe to add abstract classes and private constructors to the future version of AS. It does seem silly not to support this stuff. -Chris ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Interfaces: what are the advantages?
Ian, That being the case, I can't quite see how intrinsics apply, as by their nature they include no implementation at all. Ah, good point. I just got excited when I saw that variable in there. It is one step closer to abstract. Oddly, in AS3 Macrodobe have taken out the facility to mark a constructor as anything else than public I think they're following the Java language closely, which only has public constructors. Scott On 10/14/06, Ian Thomas <[EMAIL PROTECTED]> wrote: Scott, To me, an abstract class is one which has a partial - but incomplete - implementation i.e. you should never find yourself writing new SomeAbstractClass() - you should only ever be creating objects derived from it. The abstract class contains some useful re-usable stuff, but can't function on its own. Halfway between an interface and a class, if you like. That being the case, I can't quite see how intrinsics apply, as by their nature they include no implementation at all. The simplest way of faking an abstract class in AS2, I think, is just to mark the constructor as private. (Oddly, in AS3 Macrodobe have taken out the facility to mark a constructor as anything else than public - and I really can't fingure out why.) Ian On 10/14/06, slangeberg <[EMAIL PROTECTED]> wrote: > According to those docs, it looks like it's intended to bring forward > type-checking from AS1 classes. However, does anyone know if an intrinsic > class could be used as an abstract class? ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com -- : : ) Scott ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Interfaces: what are the advantages?
Scott, To me, an abstract class is one which has a partial - but incomplete - implementation i.e. you should never find yourself writing new SomeAbstractClass() - you should only ever be creating objects derived from it. The abstract class contains some useful re-usable stuff, but can't function on its own. Halfway between an interface and a class, if you like. That being the case, I can't quite see how intrinsics apply, as by their nature they include no implementation at all. The simplest way of faking an abstract class in AS2, I think, is just to mark the constructor as private. (Oddly, in AS3 Macrodobe have taken out the facility to mark a constructor as anything else than public - and I really can't fingure out why.) Ian On 10/14/06, slangeberg <[EMAIL PROTECTED]> wrote: According to those docs, it looks like it's intended to bring forward type-checking from AS1 classes. However, does anyone know if an intrinsic class could be used as an abstract class? ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Interfaces: what are the advantages?
Hi Ray, Yes - but why would you, if the language spec already supports interfaces? Using interfaces is a much more 'standard' way (i.e. the same sort of thing you'd do if you were talking to dynamic libraries in other languages). I still see intrinsics as a bit of a hack. "These classes are internal to the Flash Player, honest! Don't look for their implementation". Note the line from the page you link to: "This keyword was not meant for general purpose use..." Still - I'd imagine, like many of these things, in the end it comes down to personal taste. :-) Whatever gets the job done... Ian On 10/14/06, Ray Chuan <[EMAIL PROTECTED]> wrote: Hi, can't this be done with intrinsics? http://livedocs.macromedia.com/flash/8/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=1879.html ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Interfaces: what are the advantages?
can't this be done with intrinsics?
Ray, an interface does not include variables, so this example looks more
like an Abstract class.
intrinsic class Circle {
var radius:Number;
function Circle(radius:Number);
function getArea():Number;
function getDiameter():Number;
function setRadius(param_radius:Number):Number;
}
According to those docs, it looks like it's intended to bring forward
type-checking from AS1 classes. However, does anyone know if an intrinsic
class could be used as an abstract class?
Scott
On 10/14/06, Ray Chuan <[EMAIL PROTECTED]> wrote:
Hi,
can't this be done with intrinsics?
http://livedocs.macromedia.com/flash/8/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=1879.html
On 10/14/06, Ian Thomas <[EMAIL PROTECTED]> wrote:
> On 10/13/06, Jim Kremens <[EMAIL PROTECTED]> wrote:
> > "I understand what interfaces are, but I'm not entirely clear on when
> > they become advantageous to use. Anyone care to shed some light?"
>
> Interfaces are also very handy when you want to put the actual
> implementation code for a class in one .swf, but still get all the
> type-checking when writing code in another .swf that'll use it. Both
> .swfs include the interface code, but only the implementing .swf needs
> to include a concrete implementation of the class.
>
> Ian
> ___
> Flashcoders@chattyfig.figleaf.com
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
>
--
Cheers,
Ray Chuan
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
--
: : ) Scott
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
Re: [Flashcoders] Interfaces: what are the advantages?
Hi, can't this be done with intrinsics? http://livedocs.macromedia.com/flash/8/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=1879.html On 10/14/06, Ian Thomas <[EMAIL PROTECTED]> wrote: On 10/13/06, Jim Kremens <[EMAIL PROTECTED]> wrote: > "I understand what interfaces are, but I'm not entirely clear on when > they become advantageous to use. Anyone care to shed some light?" Interfaces are also very handy when you want to put the actual implementation code for a class in one .swf, but still get all the type-checking when writing code in another .swf that'll use it. Both .swfs include the interface code, but only the implementing .swf needs to include a concrete implementation of the class. Ian ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com -- Cheers, Ray Chuan ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Interfaces: what are the advantages?
On 10/13/06, Jim Kremens <[EMAIL PROTECTED]> wrote: "I understand what interfaces are, but I'm not entirely clear on when they become advantageous to use. Anyone care to shed some light?" Interfaces are also very handy when you want to put the actual implementation code for a class in one .swf, but still get all the type-checking when writing code in another .swf that'll use it. Both .swfs include the interface code, but only the implementing .swf needs to include a concrete implementation of the class. Ian ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Interfaces: what are the advantages?
"I understand what interfaces are, but I'm not entirely clear on when they become advantageous to use. Anyone care to shed some light?" I find them really useful for implementing the strategy pattern, and I find the strategy pattern to be extremely useful in Flash. Let's say, for example, that you're implementing a number of different types of lists. You could: - make an interface, IList, that declares all of the methods you think lists will need and the arguments they will accept. - Make a base class, List, that implements those methods. - Create subinterfaces of IList, like IHashMap, or whatever, which override methods and add additional methods and subclasses of List that implement those new interfaces. Here's why this is good: - You have tight coupling between all list classes. When you know how one works, you pretty much know how they all work. - If you want to make changes to all of the classes in the list package, do so in IList. All of the classes that implement IList will be forced to adopt those changes. - You get rid of a lot of conditional statements. All of the things in the list package you created above have at least 2 valid types: IList and their own class type. Let's say you have some other widget or something that accepts lists as a dataprovider, for example. Without this sort of architecture, you might need branching conditionals 'if myList instanceOf HashMap, then do this.' But here they all share the type IList. So you can call common methods on them that were declared in the interfaces, and be sure that they will produce predictable results. All of that said, interfaces create more work. To make them viable, you really need an editor that supports this kind of coding. For example, if I change method signatures in an interface, FDT lets me know everywhere else I need to change them. Without FDT, I probably wouldn't use interfaces. Also, I think they make sense when working on a framework or large project. For simpler one-off projects, I don't use them. For me, they are really just a way to make it easier to implement design patterns in Flash, and especially the Strategy Pattern. Here are a few links: http://en.wikipedia.org/wiki/Strategy_pattern http://ootips.org/strategy-vs-case.html http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/StrategyPattern.htm Jim Kremens ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Interfaces: what are the advantages?
Mendelsohn, Michael wrote:
Hi list...
I understand what interfaces are, but I'm not entirely clear on when
they become advantageous to use. Anyone care to shed some light?
Thanks,
- Michael M.
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
Polymorphism for one
class a implements interface{
}
class b implements interface{
}
class c{
var myVar:interface;
function c(instance:a){
myVar = instance;
}
}
Second, keeping yourself in check. Interfaces allow you to dictate the
rules for a "breed" of class. An example:
Let's say you're designing an application to keep track on men and
women. Your app *needs* a function, say "update" to be in all instances
of man and woman, but in the man and woman classes the update functions
are so dissimilar there's no point in using inheritance. Instead,
implement a "human" interface, which dictates explicitly that both need
a uniform update function. Problem solved in terms of type checking,
problem solved in terms of keeping yourself on top of why you did what.
To me, interfaces are like inheritance-free polymorphism first, and
debug tool second.
- Andreas R
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
Re: [Flashcoders] Interfaces: what are the advantages?
Design principle:
'Code to interface, not implementation'.
Say you have classic MusicPlayer interface (and this is all psuedo-code):
play()
stop()
ok, now I've got CDPlayer implements MusicPlayer:
play()
stop()
==
nextTrack()
and TapePlayer implements MusicPlayer:
play()
stop()
==
eatTape()
Then, we have system (?RemoteControl) which uses both and perhaps many more
MusicPlayers:
var musicPlayer:MusicPlayer
function setPlayer( player:MusicPlayer ){...}
function play() {
musicPlayer.play()
}
We can now change behavior of RemoControl at runtime.
A good example is Strategy pattern:
http://en.wikipedia.org/wiki/Strategy_pattern
Scott
On 10/13/06, Mendelsohn, Michael <[EMAIL PROTECTED]> wrote:
Hi list...
I understand what interfaces are, but I'm not entirely clear on when
they become advantageous to use. Anyone care to shed some light?
Thanks,
- Michael M.
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
--
: : ) Scott
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
Re: [Flashcoders] interfaces and objects
'Fraid not. One to chalk down to experience, I guess. Oh well. I'm making the move to 8 shortly myself, once this latest crop of projects are out of the way... Ian On 2/1/06, j.c.wichman <[EMAIL PROTECTED]> wrote: > > Life is so unfair :) > > I had to switch to flash 8 to make it go away... My mind finally at > piece... > And now you tell me that it wasn't mx2004 :), please tell me you are a mac > user ;)) > > Greetz > Hans > ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] interfaces and objects
Life is so unfair :) I had to switch to flash 8 to make it go away... My mind finally at piece... And now you tell me that it wasn't mx2004 :), please tell me you are a mac user ;)) Greetz Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Thomas Sent: Wednesday, February 01, 2006 1:31 PM To: Flashcoders mailing list Subject: Re: [Flashcoders] interfaces and objects MX2004 Cheers, Ian On 2/1/06, j.c.wichman <[EMAIL PROTECTED]> wrote: > > Hi Ian, > Which flash version are you using? > I had other problems yesterday with extending CollectionImpl due to my > flash version (mx 2004), which worked just fine in flash 8. Might be > the same in this case. > > Are you using 7 or 8? > > Thanks! > Hans > ___ 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] interfaces and objects
MX2004 Cheers, Ian On 2/1/06, j.c.wichman <[EMAIL PROTECTED]> wrote: > > Hi Ian, > Which flash version are you using? > I had other problems yesterday with extending CollectionImpl due to my > flash > version (mx 2004), which worked just fine in flash 8. Might be the same in > this case. > > Are you using 7 or 8? > > Thanks! > Hans > ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] interfaces and objects
Hi, Yes steve was completely right about that. Thanks all! H -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Thomas Sent: Wednesday, February 01, 2006 1:19 PM To: Flashcoders mailing list Subject: Re: [Flashcoders] interfaces and objects Then as Steve says, sounds like a compiler bug. Ian On 2/1/06, j.c.wichman <[EMAIL PROTECTED]> wrote: > > Hi, > No confusion here ;) except maybe for my fuzzy explanation ;). > I did: > interface IWorldPart > class WorldPart implements IWorldPart > class SomeWorldPartSubclass extends WorldPart > > then either > var myPart:WorldPart = new SomeWorldPartSubclass(); or var > myPart:IWorldPart = new SomeWorldPartSubclass(); > > As you described, however collection.addItem (myPart) only works in > the first case and not in the second. > Probably becoz flash thinks IWorldPart is not an object. I changed it to : > var myPart:Object = new SomeWorldPartSubclass(); And it works fine > (just as var myPart:WorldPart = new > SomeWorldPartSubclass();) by the way. > > Thanks for your comments, > H > ___ 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] interfaces and objects
Hi, At me too ;), it's indeed flash 7 compiler bug it seems, it compiles fine in flash 8. Time for me to switch ;). Greetz Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Thomas Sent: Wednesday, February 01, 2006 1:22 PM To: Flashcoders mailing list Subject: Re: [Flashcoders] interfaces and objects But it should. :-) Like I said, my quick test of var myPart:SomeInterface=new SomeConcreteImplementingSomeInterface(); trace(myPart instanceof Object); Traces 'true'. Which is what I'd expect. I really don't understand why you're getting an error with myCollection. I know you've solved your immediate problem - but this is niggling at me now... ;-) Ian On 2/1/06, j.c.wichman <[EMAIL PROTECTED]> wrote: > > > Hi, > I know u can't instantiate an interface, which wasn't what I was > trying to do ;), I was declaring a variable to be of type > SomeInterface (instantiating it with SomeConcreteClass), which > apparently is not regarded by flash then of being of type Object as > well. > Got it figured out now ;) > > Thanks > H > ___ 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] interfaces and objects
Yup, sorry it was my mistake... (I read the message too fast) ;-)
j.c.wichman a écrit :
Hi,
I know u can't instantiate an interface, which wasn’t what I was trying to
do ;), I was declaring a variable to be of type SomeInterface (instantiating
it with SomeConcreteClass), which apparently is not regarded by flash then
of being of type Object as well.
Got it figured out now ;)
Thanks
H
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Julien
Vignali
Sent: Wednesday, February 01, 2006 12:49 PM
To: Flashcoders mailing list
Subject: Re: [Flashcoders] interfaces and objects
Well, you can't instanciate an interface, you need first a concrete class
that implements the interface...
Your code should be:
interface IWorldPart {}
class SomeWorldPartSubclass implements IWorldPart {} var
myPart:SomeWorldPartSubclass = new SomeWorldPartSubclass();
myCollection.addItem(myPart);
j.c.wichman a écrit :
Hi,
i'm using a collection, which requires items of type Object to be added.
I've declared an interface which gives me something like:
- interface IWorldPart
- a class implementing WorldPart
now somewhere else i do:
var myPart:IWorldPart = new SomeWorldPartSubclass();
myCollection.addItem (myPart);
The last statement gives a type error, if i replace the first with var
myPart:WorldPart = new ... all goes well.
From what I can remember from Java (which I admit, seems ages ago ;)),
this
first should be no problem at all.
Does anyone know why this is not allowed in Flash?
thanks in advance.
Hans
___
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] interfaces and objects
But it should. :-) Like I said, my quick test of var myPart:SomeInterface=new SomeConcreteImplementingSomeInterface(); trace(myPart instanceof Object); Traces 'true'. Which is what I'd expect. I really don't understand why you're getting an error with myCollection. I know you've solved your immediate problem - but this is niggling at me now... ;-) Ian On 2/1/06, j.c.wichman <[EMAIL PROTECTED]> wrote: > > > Hi, > I know u can't instantiate an interface, which wasn't what I was trying to > do ;), I was declaring a variable to be of type SomeInterface > (instantiating > it with SomeConcreteClass), which apparently is not regarded by flash then > of being of type Object as well. > Got it figured out now ;) > > Thanks > H > ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] interfaces and objects
Hi Ian,
Which flash version are you using?
I had other problems yesterday with extending CollectionImpl due to my flash
version (mx 2004), which worked just fine in flash 8. Might be the same in
this case.
Are you using 7 or 8?
Thanks!
Hans
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Thomas
Sent: Wednesday, February 01, 2006 1:05 PM
To: Flashcoders mailing list
Subject: Re: [Flashcoders] interfaces and objects
No, you can't instantiate an interface. But I don't think Hans was doing
that.
There's no problem with typing:
interface IWorldPart {}
class SomeWorldPartSubclass implements IWorldPart {}
var myPart:IWorldPart = new SomeWorldPartSubclass(); /* Note
INTERFACE-typed var, not concrete */
myCollection.addItem(myPart);
Works fine for me on a quick test. A sanity check of trace(myPart instanceof
Object); //traces true shows that you should be able to use the myPart
variable everywhere that an Object is expected.
Ian
On 2/1/06, Julien Vignali <[EMAIL PROTECTED]> wrote:
>
> Well, you can't instanciate an interface, you need first a concrete
> class that implements the interface...
>
> Your code should be:
>
> interface IWorldPart {}
> class SomeWorldPartSubclass implements IWorldPart {} var
> myPart:SomeWorldPartSubclass = new SomeWorldPartSubclass();
> myCollection.addItem(myPart);
>
___
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] interfaces and objects
Then as Steve says, sounds like a compiler bug. Ian On 2/1/06, j.c.wichman <[EMAIL PROTECTED]> wrote: > > Hi, > No confusion here ;) except maybe for my fuzzy explanation ;). > I did: > interface IWorldPart > class WorldPart implements IWorldPart > class SomeWorldPartSubclass extends WorldPart > > then either > var myPart:WorldPart = new SomeWorldPartSubclass(); or var > myPart:IWorldPart > = new SomeWorldPartSubclass(); > > As you described, however collection.addItem (myPart) only works in the > first case and not in the second. > Probably becoz flash thinks IWorldPart is not an object. I changed it to : > var myPart:Object = new SomeWorldPartSubclass(); > And it works fine (just as var myPart:WorldPart = new > SomeWorldPartSubclass();) by the way. > > Thanks for your comments, > H > ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] interfaces and objects
Hi,
I know u can't instantiate an interface, which wasnt what I was trying to
do ;), I was declaring a variable to be of type SomeInterface (instantiating
it with SomeConcreteClass), which apparently is not regarded by flash then
of being of type Object as well.
Got it figured out now ;)
Thanks
H
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Julien
Vignali
Sent: Wednesday, February 01, 2006 12:49 PM
To: Flashcoders mailing list
Subject: Re: [Flashcoders] interfaces and objects
Well, you can't instanciate an interface, you need first a concrete class
that implements the interface...
Your code should be:
interface IWorldPart {}
class SomeWorldPartSubclass implements IWorldPart {} var
myPart:SomeWorldPartSubclass = new SomeWorldPartSubclass();
myCollection.addItem(myPart);
j.c.wichman a écrit :
> Hi,
> i'm using a collection, which requires items of type Object to be added.
>
> I've declared an interface which gives me something like:
> - interface IWorldPart
> - a class implementing WorldPart
>
> now somewhere else i do:
> var myPart:IWorldPart = new SomeWorldPartSubclass();
> myCollection.addItem (myPart);
>
> The last statement gives a type error, if i replace the first with var
> myPart:WorldPart = new ... all goes well.
>
>>From what I can remember from Java (which I admit, seems ages ago ;)),
>>this
> first should be no problem at all.
>
> Does anyone know why this is not allowed in Flash?
>
> thanks in advance.
> Hans
>
>
> ___
> 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] interfaces and objects
Hi, No confusion here ;) except maybe for my fuzzy explanation ;). I did: interface IWorldPart class WorldPart implements IWorldPart class SomeWorldPartSubclass extends WorldPart then either var myPart:WorldPart = new SomeWorldPartSubclass(); or var myPart:IWorldPart = new SomeWorldPartSubclass(); As you described, however collection.addItem (myPart) only works in the first case and not in the second. Probably becoz flash thinks IWorldPart is not an object. I changed it to : var myPart:Object = new SomeWorldPartSubclass(); And it works fine (just as var myPart:WorldPart = new SomeWorldPartSubclass();) by the way. Thanks for your comments, H -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Thomas Sent: Wednesday, February 01, 2006 12:36 PM To: Flashcoders mailing list Subject: Re: [Flashcoders] interfaces and objects Um... not quite sure what you're up to here - but it sounds like you're getting a bit confused between IWorldPart and WorldPart. What you need is: interface IWorldPart class SomeWorldPartSubclass implements IWorldPart then var myPart:IWorldPart = new SomeWorldPartSubclass(); should be fine. _OR_ interface WorldPart class SomeWorldPartSubclass implements WorldPart then var myPart:WorldPart = new SomeWorldPartSubclass(); Not quite sure why your description mentions both IWorldPart and WorldPart - unless WorldPart implements IWorldPart..? In which case you're looking for: interface IWorldPart class WorldPart implements IWorldPart class SomeWorldPartSubclass extends WorldPart then either var myPart:WorldPart = new SomeWorldPartSubclass(); or var myPart:IWorldPart = new SomeWorldPartSubclass(); should both work... HTH, Ian On 2/1/06, j.c.wichman <[EMAIL PROTECTED]> wrote: > > Hi, > i'm using a collection, which requires items of type Object to be added. > > I've declared an interface which gives me something like: > - interface IWorldPart > - a class implementing WorldPart > > now somewhere else i do: > var myPart:IWorldPart = new SomeWorldPartSubclass(); > myCollection.addItem (myPart); > > The last statement gives a type error, if i replace the first with var > myPart:WorldPart = new ... all goes well. > ___ 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] interfaces and objects
No, you can't instantiate an interface. But I don't think Hans was doing
that.
There's no problem with typing:
interface IWorldPart {}
class SomeWorldPartSubclass implements IWorldPart {}
var myPart:IWorldPart = new SomeWorldPartSubclass(); /* Note
INTERFACE-typed var, not concrete */
myCollection.addItem(myPart);
Works fine for me on a quick test. A sanity check of
trace(myPart instanceof Object); //traces true
shows that you should be able to use the myPart variable everywhere that an
Object is expected.
Ian
On 2/1/06, Julien Vignali <[EMAIL PROTECTED]> wrote:
>
> Well, you can't instanciate an interface, you need first a concrete
> class that implements the interface...
>
> Your code should be:
>
> interface IWorldPart {}
> class SomeWorldPartSubclass implements IWorldPart {}
> var myPart:SomeWorldPartSubclass = new SomeWorldPartSubclass();
> myCollection.addItem(myPart);
>
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] interfaces and objects
Well, you can't instanciate an interface, you need first a concrete
class that implements the interface...
While you cannot instantiate an interface, you can assign an object
that is an instance of a class that does implement the interface to a
variable that is typed to the interface.
Your code should be:
interface IWorldPart {}
class SomeWorldPartSubclass implements IWorldPart {}
var myPart:SomeWorldPartSubclass = new SomeWorldPartSubclass();
myCollection.addItem(myPart);
I think what the OP is saying is that he wants to do this (based on
your example):
var myPart:IWorldPart = new SomeWorldPartSubclass();
...which compiles just fine, but the compiler baulks at the following
statement...
myCollection.addItem(myPart);
If I read correctly, the addItem method is expecting one argument of
type Object, and the compiler seems to think that an object of type
IWorldPart (i.e. of a class implementing the IWorldPart interface)
cannot be stored in a variable of type Object. I don't have time to
test this, but if this really is the case then it's a compiler bug.
--
Steve Webster
Head of Development
Featurecreep Ltd.
www.featurecreep.com
14 Orchard Street, Bristol, BS1 5EH
0117 905 5047
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] interfaces and objects
Well, you can't instanciate an interface, you need first a concrete
class that implements the interface...
Your code should be:
interface IWorldPart {}
class SomeWorldPartSubclass implements IWorldPart {}
var myPart:SomeWorldPartSubclass = new SomeWorldPartSubclass();
myCollection.addItem(myPart);
j.c.wichman a écrit :
Hi,
i'm using a collection, which requires items of type Object to be added.
I've declared an interface which gives me something like:
- interface IWorldPart
- a class implementing WorldPart
now somewhere else i do:
var myPart:IWorldPart = new SomeWorldPartSubclass();
myCollection.addItem (myPart);
The last statement gives a type error, if i replace the first with var
myPart:WorldPart = new ... all goes well.
From what I can remember from Java (which I admit, seems ages ago ;)), this
first should be no problem at all.
Does anyone know why this is not allowed in Flash?
thanks in advance.
Hans
___
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] interfaces and objects
Um... not quite sure what you're up to here - but it sounds like you're getting a bit confused between IWorldPart and WorldPart. What you need is: interface IWorldPart class SomeWorldPartSubclass implements IWorldPart then var myPart:IWorldPart = new SomeWorldPartSubclass(); should be fine. _OR_ interface WorldPart class SomeWorldPartSubclass implements WorldPart then var myPart:WorldPart = new SomeWorldPartSubclass(); Not quite sure why your description mentions both IWorldPart and WorldPart - unless WorldPart implements IWorldPart..? In which case you're looking for: interface IWorldPart class WorldPart implements IWorldPart class SomeWorldPartSubclass extends WorldPart then either var myPart:WorldPart = new SomeWorldPartSubclass(); or var myPart:IWorldPart = new SomeWorldPartSubclass(); should both work... HTH, Ian On 2/1/06, j.c.wichman <[EMAIL PROTECTED]> wrote: > > Hi, > i'm using a collection, which requires items of type Object to be added. > > I've declared an interface which gives me something like: > - interface IWorldPart > - a class implementing WorldPart > > now somewhere else i do: > var myPart:IWorldPart = new SomeWorldPartSubclass(); > myCollection.addItem (myPart); > > The last statement gives a type error, if i replace the first with var > myPart:WorldPart = new ... all goes well. > ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
