Re: [Flashcoders] Compiling with self-reference
Hi, you said: restrictive not to be able to refer to a superclass within a subclass - that's enforcing an arbitrary design principle. But that's not what you are doing: you are referring to a subclass within a superclass. And with this "So it seems pretty reasonable to me that all my objects know about all the other objects", although it might be reasonable, you are increasing the complexity of your application. It easier when objects don't know about each other, then when they know about each object. In your example your superclass can no longer exist on its own. It MUST have a subclass of a certain type. Believe me, that's weird, even for flash:)). Your solution (adding another layer) spells coding horror to me. You tried something to fool the compiler, and hey! it worked!. Compare: class Animal { private var isEatenBy:Animal; } class Cat extends Animal { . } class Bird Extends Animal { function Bird() { isEatenBy = new Cat(); } } with: class Animal { private var isEatenBy:Cat; } class Cat extends Animal { ///WHOOPS problem here, since isEatenBy is of type Cat i cannot put a big dog or car here } class Bird Extends Animal { function Bird() { isEatenBy = new Cat(); //this still works ofcourse, since its the only case that will work } } greetz JC On 3/22/07, Danny Kodicek <[EMAIL PROTECTED]> wrote: > Danny Kodicek wrote: > > It's a shame: My object structure has a bunch of objects in a tree > > structure, all of which inherit the same base class. I'd > like them all > > to have a reference to the top-level node object, but I > have to refer > > to it as an Object instead of its actual class name because > otherwise > > it can't compile. > > > You are mixing Classes and Instances. Classes inherit > properties and methods from other classes. > How the instances are linked together at execution time is > another matter. Well, not really. I may use the words 'class' and 'object' interchangeably on occasion, but I'm quite aware of the distinction. Classes have properties, instances give those properties values, classes define the kinds of data those values can take. I don't think my example is that odd, really. It seems unnecessarily restrictive not to be able to refer to a superclass within a subclass - that's enforcing an arbitrary design principle. Danny ___ 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 ___ 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] Compiling with self-reference
> Danny Kodicek wrote: > > It's a shame: My object structure has a bunch of objects in a tree > > structure, all of which inherit the same base class. I'd > like them all > > to have a reference to the top-level node object, but I > have to refer > > to it as an Object instead of its actual class name because > otherwise > > it can't compile. > > > You are mixing Classes and Instances. Classes inherit > properties and methods from other classes. > How the instances are linked together at execution time is > another matter. Well, not really. I may use the words 'class' and 'object' interchangeably on occasion, but I'm quite aware of the distinction. Classes have properties, instances give those properties values, classes define the kinds of data those values can take. I don't think my example is that odd, really. It seems unnecessarily restrictive not to be able to refer to a superclass within a subclass - that's enforcing an arbitrary design principle. Danny ___ 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] Compiling with self-reference
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Hans Wichman > Sent: 22 March 2007 12:39 > To: flashcoders@chattyfig.figleaf.com > Subject: Re: [Flashcoders] Compiling with self-reference > Importance: High > > Hi, > this > class Clarss { >var pRoot:Clarss2 >function Clarss() { >} > } > class Clarss2 extends Clarss { >function Clarss2() { >} > } > > looks like a design error to me. One of the reasons you would > use inheritance is polymorphism, and reducing complexity. A > super class having to know the type of its subclasses is not > good practice. Why not keep the reference pRoot:Clarss? You > can stick any subclass in there. It depends on the circumstances. My main reason for using inheritance is code reuse: putting common code into ancestors. In my case, I'm not writing objects for reuse elsewhere. So it seems pretty reasonable to me that all my objects know about all the other objects. Here's a simplified example of the structure I'm trying to create: RootElement extends Element SimpleBlock extends BlockElement extends Element TextItem extends ItemElement extends Element the Element object has a pChildren:Array (empty for items) and pParent:Element (undefined for Root) property, creating a tree structure. Each element also has a direct reference pRoot:RootElement to the tree root (this is the bit that doesn't work). I think this makes good sense. I could shore it up by adding an additional layer: RootElement extends Element SimpleBlock extends BlockElement extends ChildElement extends Element TextItem extends ItemElement extends ChildElement extends Element Here, ChildElement is the one that has the pRoot property, eliminating the circular reference. But it seems a bit silly to have to add an empty class just for the sake of a single property. Danny ___ 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] Compiling with self-reference
Hi Danny, Maybe make it a public var pParent:Clarss; or if you don't want your var to be accessed directly outside the class (best practice) class Clarss { private var _pParent:Clarss; function Clarss(tParent:Clarss) { pParent = (tParent != undefined) ? tParent : this; } public function get pParent():Clarss { return _pParent; } public function set pParent(value:Clarss):Void { _pParent = value; } } HTH Alain -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Danny Kodicek Sent: 22 mars 2007 07:16 To: flashcoders@chattyfig.figleaf.com Subject: [Flashcoders] Compiling with self-reference Slightly complicated and not terribly important but annoying: It's possible for a class to compile while self-referring: class Clarss { var pParent:Clarss; function Clarss(tParent:Clarss) { if (tParent != undefined) { pParent = tParent; } } } This compiles fine. But with inheritance this no longer works: class Clarss { var pRoot:Clarss2 function Clarss() { } } class Clarss2 extends Clarss { function Clarss2() { } } Now the compiler gets confused by the circular reference and tells me "**Error** C:\...Clarss.as: Line 1: The name of this class, 'Clarss', conflicts with the name of another class that was loaded, 'Clarss'." It's a shame: My object structure has a bunch of objects in a tree structure, all of which inherit the same base class. I'd like them all to have a reference to the top-level node object, but I have to refer to it as an Object instead of its actual class name because otherwise it can't compile. Danny ___ 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 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.17/730 - Release Date: 2007-03-22 07:44 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.17/730 - Release Date: 2007-03-22 07:44 ___ 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] Compiling with self-reference
Danny Kodicek wrote: Slightly complicated and not terribly important but annoying: It's possible for a class to compile while self-referring: class Clarss { var pParent:Clarss; function Clarss(tParent:Clarss) { if (tParent != undefined) { pParent = tParent; } } } This compiles fine. But with inheritance this no longer works: class Clarss { var pRoot:Clarss2 function Clarss() { } } class Clarss2 extends Clarss { function Clarss2() { } } Now the compiler gets confused by the circular reference and tells me "**Error** C:\...Clarss.as: Line 1: The name of this class, 'Clarss', conflicts with the name of another class that was loaded, 'Clarss'." It's a shame: My object structure has a bunch of objects in a tree structure, all of which inherit the same base class. I'd like them all to have a reference to the top-level node object, but I have to refer to it as an Object instead of its actual class name because otherwise it can't compile. You are mixing Classes and Instances. Classes inherit properties and methods from other classes. How the instances are linked together at execution time is another matter. Read some Actionscript books and if you want to do something this sophisticated read the design pattern book. What you want to do is pretty easy if you design it right. This is a very simple ActionScript application once you get your head around the tools. Actionscript and Java are pretty similar so you can read some books on designing with Java if you can not get one of the ActionScript books. Which books have you read. Perhaps other in the forum can comment on those books and suggest books that they found helpful. Are you defining each class in its own .as file? Danny ___ 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 ___ 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] Compiling with self-reference
ps if you still need to do what you are trying, compiling twice or thrice might help:) On 3/22/07, Hans Wichman <[EMAIL PROTECTED]> wrote: Hi, this class Clarss { var pRoot:Clarss2 function Clarss() { } } class Clarss2 extends Clarss { function Clarss2() { } } looks like a design error to me. One of the reasons you would use inheritance is polymorphism, and reducing complexity. A super class having to know the type of its subclasses is not good practice. Why not keep the reference pRoot:Clarss? You can stick any subclass in there. (ps you might want to read about the en.wikipedia.org/wiki/*Liskov*_* substitution*_*principle )* ** *greetz* *JC* ** On 3/22/07, Danny Kodicek <[EMAIL PROTECTED]> wrote: > > Slightly complicated and not terribly important but annoying: > > It's possible for a class to compile while self-referring: > > class Clarss { >var pParent:Clarss; >function Clarss(tParent:Clarss) { >if (tParent != undefined) { >pParent = tParent; >} >} > } > > This compiles fine. But with inheritance this no longer works: > > class Clarss { >var pRoot:Clarss2 >function Clarss() { >} > } > class Clarss2 extends Clarss { >function Clarss2() { >} > } > > Now the compiler gets confused by the circular reference and tells me > "**Error** C:\...Clarss.as: Line 1: The name of this class, 'Clarss', > conflicts with the name of another class that was loaded, 'Clarss'." > > > It's a shame: My object structure has a bunch of objects in a tree > structure, all of which inherit the same base class. I'd like them all > to > have a reference to the top-level node object, but I have to refer to it > as > an Object instead of its actual class name because otherwise it can't > compile. > > Danny > > ___ > 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 > ___ 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] Compiling with self-reference
Hi, this class Clarss { var pRoot:Clarss2 function Clarss() { } } class Clarss2 extends Clarss { function Clarss2() { } } looks like a design error to me. One of the reasons you would use inheritance is polymorphism, and reducing complexity. A super class having to know the type of its subclasses is not good practice. Why not keep the reference pRoot:Clarss? You can stick any subclass in there. (ps you might want to read about the en.wikipedia.org/wiki/*Liskov*_* substitution*_*principle )* ** *greetz* *JC* ** On 3/22/07, Danny Kodicek <[EMAIL PROTECTED]> wrote: Slightly complicated and not terribly important but annoying: It's possible for a class to compile while self-referring: class Clarss { var pParent:Clarss; function Clarss(tParent:Clarss) { if (tParent != undefined) { pParent = tParent; } } } This compiles fine. But with inheritance this no longer works: class Clarss { var pRoot:Clarss2 function Clarss() { } } class Clarss2 extends Clarss { function Clarss2() { } } Now the compiler gets confused by the circular reference and tells me "**Error** C:\...Clarss.as: Line 1: The name of this class, 'Clarss', conflicts with the name of another class that was loaded, 'Clarss'." It's a shame: My object structure has a bunch of objects in a tree structure, all of which inherit the same base class. I'd like them all to have a reference to the top-level node object, but I have to refer to it as an Object instead of its actual class name because otherwise it can't compile. Danny ___ 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 ___ 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