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_Partsfile=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?
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, can't this be done with intrinsics? http://livedocs.macromedia.com/flash/8/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Partsfile=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?
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_Partsfile=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 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_Partsfile=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?
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?
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?
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: 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?
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?
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
