Sorry, no class variables in Director. Since Director doesn't have any
notion of encapsulation/data hidding (like C++ public, protected, private),
then static variable don't really make sense because they degenerate into
globals.

Patrick

> -----Original Message-----
> From: victor vina [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 23, 2001 7:49 AM
> To: [EMAIL PROTECTED]
> Subject: <lingo-l> Re: Static Variables
> 
> 
> 
> On Thu, 18 Jan 2001 Christopher Watson wrote:
> 
> > Is there a better way to implement a class variable in a 
> parent script?
> > 
> > And, is the answer going to be "use a global"? I hope not, 
> because I don't
> > want to.
> 
> From what I understand from your explanation, I believe you 
> are referring to
> the ancestor property.
> 
> If every time you declare a child object, you declare the 
> parent as the
> child's ancestor, the properties of any objects higher in the 
> hierarchy can
> be accessed without specifying the whole 'path' to that 
> particular object.
> 
> i.e.
> 
> --- parent object:
> 
>     myChildObject = new (script"childObject",me)
> 
> --- child object:
> 
> property ancestor
> 
> on new me,whichAncestor
>     ancestor = whichAncestor
>     return me
> end
> 
> Then, at any given child object, you can access any 
> properties of the root
> object (or any other child on the branch if a property with 
> the same name
> exits), with:
> 
> me.classVariable
> 
> Director will start looking in the same instance, but if the 
> property is not
> found, it will 'take the walk up the linked list', until it finds it.
> 
> In your case, define your 'class variables' in your root 
> object, all its
> children will be able to access them, by preceding the name 
> of the property
> by 'me'. Simply make sure to assign unique names to these variables.
> 
> I don't know if OOP purists agree with this approach, since you are
> accessing an object's properties from the outside, but I've 
> used it quite
> often with success, specially for the tree-shaped structures 
> formed when
> parsing an XML document.
>   
> Let me know if this answers your question.
> 
> victor
> 
> 
> > The properties within a parent script are equivalent to 
> instance variables.
> > But I want to implement the equivalent of a class variable 
> in my parent
> > script, so that all child objects created from that parent 
> script can take
> > into account the value held within that class variable when 
> performing tasks
> > within their instance methods.
> > 
> > Now, in my particular case, I'm not creating discrete child 
> objects that
> > each live in a world of their own. All the child objects 
> created from my
> > parent script are nodes within a tree (an XML document), 
> with one of those
> > child objects representing the root of that tree. The root 
> has child nodes,
> > and those child nodes have child nodes, etc. Taking that 
> into consideration,
> > I though that I had come up with a fairly simple way of 
> faking a class
> > variable.
> > 
> > If I were to maintain the tree as a linked list (meaning, 
> if the parent
> > script had a property which held a reference to the child 
> object which is
> > its parent node), I would always be able to recurse to the 
> root from any
> > node and retrieve the value held within the "class 
> variable" property in the
> > root node child object. Since the root node child object 
> never changes for
> > the existence of the tree, setting a property value in the 
> root would be the
> > same as setting the value for all the children, as long as 
> they all went to
> > the root to look for that value.
> > 
> > The problem with this approach is that every time a node is 
> called upon to
> > execute its method for forming the textual version of its 
> part of the XML
> > document, it must take that walk up the linked list to get 
> the value of that
> > property from the root node. It's the same walk for every 
> single element
> > within an XML document. And you know how complex XML docs can get.
> > 
> > It works. But it seems terribly ineffient to me.
> 
> 
> [To remove yourself from this list, or to change to digest mode, go to
> http://www.penworks.com/LUJ/lingo-l.cgi  To post messages to the list,
> email [EMAIL PROTECTED]  (Problems, email [EMAIL PROTECTED])
> Lingo-L is for learning and helping with programming Lingo.  Thanks!]
> 

[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi  To post messages to the list,
email [EMAIL PROTECTED]  (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo.  Thanks!]

Reply via email to