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