I think you might be a bit confused. "private" variables aren't ones
that are just used in individual functions, but are data that the
class needs to persist but doesn't want visible to those using the
class. These should always be declared (and I think they have to be
or the compiler will choke, at least doing strict AS2). Even if
you're extending Object (so you can do things like this.foo = "stuff"
without foo being declared) it's still a good idea to declare them.
If you're using the variable to store information that needs to
persist you really want it declared so you can be sure you're using
the right variable. If you need that data later (or if someone else
is working on the code and needs it) and it isn't declared it could be
difficult to figure out where the data is stored if it isn't declared.
And I'm not sure what you mean by your non-static variables thing
("assign to an instance"). From your example I think you're mixing
that up as well. Static variables are variables that are shared
between all instances of a particular class, and don't need an
instance of the class to be accessed (most commonly used for constants
or singleton instances). Non-static variables are tied to a
particular instance of a class.
Also, in general I don't think it's a good idea to use _global.
Global variables aren't really things that should be needed in good
OOP design. For things that you need to access from anywhere and want
only a single instance of then that's what Singletons are for, and
they're a bit safer than global variables.
The main reason I think global variables are dangerous is that they're
shared by *everything*. This makes it very difficult to avoid name
collisions unless you go with really convoluted variable names. You
have no way of knowing if some other code or package is using the same
global variable as you.
-Andy
-Andy
On 2/1/07, Paul V. <[EMAIL PROTECTED]> wrote:
Hi, I am not an expert, but from what I have read. Private variables, don't
need to be declared, so if you don't need them outside the function, or
event I think you can keep things neat by not declaring them at all until
you assign them.
And non-static variables, (dynamic variables) I would assign to an
instance. VarInstanceName = eval("varNameDynamicInstance"+i)l for exapmle
if you are using calling them via a for loop. (for i= value ; i condition
;i++){code;} .
Unless you need them outside of the sub Class you can just leave them in
the function without declairing them. If you need them in across the Class,
define them in the class function declaration. eg.
_global.myClassName=function(){
varName1 = 1;
varName2 = "Some String";}
And of course if you need them across Seperate Classes define them as
_global.varName.
Hope this helps.
Like to hear other solutions.
Paul Vds
----- Original Message -----
From: "T. Michael Keesey" <[EMAIL PROTECTED]>
To: "Flashcoders mailing list" <[email protected]>
Sent: Thursday, February 01, 2007 12:36 PM
Subject: Re: [Flashcoders] Q:Extending Class with Static
Variables,recommended practice
> On 2/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Hi
> > I'm cuurrently refactoring some code in a project with lots of extended
classes.
> >
> > What is the recommended practice in declaring static vs non-static
(private static vs private)
> > variables?
> > Should they be declared in both the super and sub classes?
> >
> > My goal is to avoid any redundant code.
> > Thanks
>
> Note:
> ----
> class SuperClass {
> public static var CONSTANT:String = "SuperClass";
> public function toString():String {
> return CONSTANT;
> }
> }
> ----
> class SubClass extends SuperClass {
> public static var CONSTANT:String = "SubClass";
> }
> ----
> var obj:SubClass = new SubClass();
> trace(obj.toString());
> // Traces "SuperClass".
> ----
>
> Overriding static variables does not work as you might expect. To get
> this to work correctly, the variable would have to be non-static.
>
> Other than that, you should never have to redundantly add anything to
> the subclass. If the superclass and the subclass both use a string
> variable called "name", just declare it in the superclass--there's no
> point at all in redeclaring it in the subclass. The whole idea of
> inheritance was created to avoid just that type of redundancy.
>
> --
> T. Michael Keesey
> Director of Technology
> Exopolis, Inc.
> 2894 Rowena Avenue Ste. B
> Los Angeles, California 90039
> --
> The Dinosauricon: http://dino.lm.com
> Parry & Carney: http://parryandcarney.com
> ISPN Forum: http://www.phylonames.org/forum/
> _______________________________________________
> [email protected]
> 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
>
>
_______________________________________________
[email protected]
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
_______________________________________________
[email protected]
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
