I need to determine if one class descends (directly or indirectly) from another.
I can do
var testInstance : Object = new ClassA();
if (testInstance is ClassB)
...
but I hate creating an instance just to test ancestry. I hoped that if (ClassA is ClassB) would work, but it does not seem to.
AS help states
isPrototypeOf(theClass:Object):Boolean
Indicates whether an instance of the Object class is in the prototype chain of the object specified as the
parameter.
I don't actually understand ActionScript prototypes (I think it might drive me insane), but I hope that Class objects have some way of tapping into their inheritance information.
Thanks
Prototypes are instances, either of the class (for class inheritance) or the parent class (for prototype inheritance). Try:
Object.prototype.extends=function (theClass:Object):boolean {
return this.prototype instanceof theClass;
}
ClassA.extends(ClassB);
ActionScript 3 shoehorns prototype inheritance into class based inheritance. You don't use prototypes much anymore in Actionscript, but it's not a complex concept and has its uses, so you'd do well to study it. Read "History of ActionScript OOP support" and "The prototype object" from "Advanced topics"
Related
I know some of the terms I use are confusing. To clarify, a driver class is basically one built on a class definition (starting with public class...) but is a method itself with the header public static void main (String args[]).
The point of this post is to resolve my serious confusion. (I am a beginner in programming)
to me, since a driver class is a method, all it does is to implement itself. But things kinda turn out to be the opposite . For example:
to implement a constructor in a driver class, you simply put down the constructor heading, like public Rectangle(), with its name being the same as that of the class. but in a class definition, to creat a object/ implement a constructor, you also have to write down happen inside that constructor, so you use the expression "type name = new type name ()".
PS: I might have used some terms wrongly, correct me thanks. Or some concept
I'll try to answer this the best way that I can.
Let's look at each of the keywords in a "driver class method" and determine the meaning.
public - this method is publicly callable by a class outside of it
static - this method is callable WITHOUT an instance of the class. In Java, look at the Math class. You don't need to instantiate an instance of the Math class to use the sqrt function (Math m = New Math(); m.sqrt(25);), you can just use Math.sqrt(25).
void - this method returns nothing
main - name of the method
Now that we have that cleared up, let's ask ourselves why these things have to be here for a "driver class"
The Virtual Machine (the program that runs your custom programs) is hard coded to look for a method named main that is public and can also be called WITHOUT CREATING AN INSTANCE OF YOUR CLASS.
So this means that when your program first runs, there is no instance of it.
To counter this, you can either create all of your methods and properties as static (generally considered bad practice) OR you can create an instance of your own class inside of it's own entry method, and begin to call the non-static methods and properties that belong to the instance.
I hope this makes sense.
A reference to the prototype object of a class or function object. The
prototype property is automatically created and attached to any class
or function object that you create. This property is static in that it
is specific to the class or function that you create. For example, if
you create a class, the value of the prototype property is shared by
all instances of the class and is accessible only as a class property.
Instances of your class cannot directly access the prototype property.
A class’s prototype object is a special instance of that class that
provides a mechanism for sharing state across all instances of a
class. At run time, when a property is not found on a class instance,
the delegate, which is the class prototype object, is checked for that
property. If the prototype object does not contain the property, the
process continues with the prototype object’s delegate checking in
consecutively higher levels in the hierarchy until Flash Player or the
Adobe Integrated Runtime finds the property.
Note: In ActionScript 3.0, prototype inheritance is not the primary
mechanism for inheritance. Class inheritance, which drives the
inheritance of fixed properties in class definitions, is the primary
inheritance mechanism in ActionScript 3.0.
So, from this I get the impression that prototypes are just static variables.. am I right?
Not exactly, a function implemented as a prototype is still executed as instance method. In a static function you don't have access to this.
Also it doesn't mean setting a prototype value to something is setting the value for every instance. It's only the fallback value, if an object of that class isn't setting it explicitly.
var o1:Object= {};
var o2:Object= {};
Object.prototype.foo = "foo";
o1.foo = "bar"
trace(o1.foo) // bar
trace(o2.foo) // foo
I currently pass a reference to my model through the constructor to any class that needs it in my simple mvc pattern, this can get annoying at times when it starts to go deeper.
How do Classes such as LoadMax allow you from anywhere to simple import the class, and do something like addChild(LoaderMax.getContent("bg"));? Replicating this should surely be a good way to have my model work, without the complexity of big frameworks?
Statics are your friend
As previous answers have noted, TweenLite/Max etc. makes heavy use of static members to get work done. This is exactly like the Math class, for example, and can be a very convenient design pattern. You have global access to the class, and that can definitely alleviate the issue of getting access to variables through deeply nested classes.
Statics are the enemy
Statics, however, bring certain problems to the table. Most importantly, they tend to reduce flexibility and modularity of classes through the often unnecessary addition of tightly coupled relationships. It's a bit like pouring concrete over your application. It does work, but changing behavior becomes difficult as project features change.
Static members != instance members
Note, very clearly, that a static member "belongs" to the class itself, and not an instance of that class. Static members have no access to instance members. This causes troubles when you want to mix these members up in logic. You tend to have to make everything static (the so-called "static-cling" effect). Static patterns are often argued to be argued to be "anti" object-oriented, for precisely this reason. Once you build a structure on a static pattern you tend to lose many of the principles that makes OOD powerful.
In small does, they're pretty nice
That all being said - TweenLite is a great example of a static pattern that is totally appropriate - its a utility package, one that logic is not dependent on. And that should probably be how you leverage statics, too.
To reduce reliance on statics, or even global vars, it does often mean writing more code, but the flexibility in app structure gained is often quite worth it. #Marty_Wallace has a pretty good solution imo.
Demeter and the Paperboy
Finally, I'll just mention the Law of Demeter, or the Principle of Least Knowledge, and the related Paperboy and the Wallet example, which is often pointed to in discussions of statics:
Each unit should have only limited knowledge about other units: only
units "closely" related to the current
unit.
Each unit should only talk to its friends; don't talk to strangers.
Only talk to your immediate friends.
Hopefully that sheds a little bit of light on a fairly complicated and not-often obvious issue.
This is done using the static namespace, however I discourage the use of this.
package
{
public class Main
{
public static function sayHell():void
{
trace("hello!");
}
}
}
You can now call sayHello() like this from anywhere in the application (assuming you've imported the class).
Main.sayHello();
Another thing you can do (to make the entire class accessible from within the application) is create a static property that refers to the class itself:
package
{
public class Something
{
public static var instance:Something;
public function Something()
{
instance = this;
}
public function someFunction():void
{
trace('hello!');
}
}
}
Which you can now use like so:
Something.instance.someFunction();
The only thing to note here is that you need to create an instance of Something for this to work to call the constructor and define instance.
What I would do
Create a base class for all objects in your application
Create a manager class that takes care of these objects
Create a setter within your base class to define the manager
Here's an example:
Base
package
{
public class Base extends Object
{
private var _manager:Manager;
public function set manager(m:Manager):void
{
_manager = m;
init();
}
protected function init():void
{
manager.someFunction();
}
public function get manager():Manager{ return _manager; }
}
}
Manager
package
{
public class Manager extends Object
{
public function someFunction():void
{
trace('hello!');
}
}
}
Now anything that extends Base will have access to anything held in Manager via the manager getter property. All you need to do is make sure you define the manager, which is easily achieved from within anything that extends Base like so:
var something:SomeExtendingClass = new SomeExtendingClass();
something.manager = manager;
The example you gave is just a static method, but to answer your question about a global instance of a class:
package myPackage
{
public var globalVariable:MyClass = new MyClass();
}
You can access it with:
import myPackage.globalVariable;
trace(globalVariable);
I think you have to rethink in which way you want to name your classes.
You can instantiate whatever class you want, at run-time, but to access a instance by name, you have to make changes in your structure. For example, the getContent() function you mentioned in LoaderMax, all it does is to search in an array for the given loader that matchs the name, among other things. You can read the name variable comment for a description.
A name that you use to identify the loader instance. This name can be fed to the getLoader() or getContent() methods or traced at any time. Each loader's name should be unique. If you don't define one, a unique name will be created automatically, like "loader21".
So in this system, you have to name every single member (loaders in this case) if you want to be able to search them. Because if I call getClassInstance("myinstance"), what is "myinstance" representing? Where should I name it?
That said, if you want to do it for DisplayObjects only, you can use getChildByName. But again, you have to name every DisplayObject (just set the name variable).
Hope this helps.
Basically, I want to modify the constructor of the Object
class. Since every class extends Object, I hope whenever any
object of any class is instantiated, the modified function will
be called.
So I did this :
Object.prototype.constructor = function (){
trace("it was called;");
};
and put a breakpoint on the trace statement.
But it didn't stop there.
The trace statement did not get executed also.
Any solutions/suggestions?
In which context are you coding?
If you're using the Flex Compiler MXMLC (default, if you're in FlashBuilder), than you could add the compiler option -es. This should make AS3 feel more like AS2 and JS and support the prototype chain inheritance.
-compiler.es alias -es
"use the ECMAScript edition 3 prototype based object model to allow dynamic overriding of prototype properties. In the prototype based object model built-in functions are implemented as dynamic properties of prototype objects. (advanced)"
I don't know, if this plays well with all the extensions Adobe added to the ECMA Script standard, like packages, namespaces and classes. But you could give it a try.
I don't think it's possible in AS-3, but it was in AS-2.
When developing in ActionScript 3, I often find myself looking for a way to achieve something similar to what is offered by python's __getattr__ / __setattr__ magic methods i.e. to be able to intercept attribute lookup on an instance, and do something custom.
Is there some acceptable way to achieve this in ActionScript 3? In AS3 attribute lookup behaves a little differently for normal (sealed) and dynamic classes -- ideally this would work in the same way for both cases. In python this works beautifully for all kinds of objects (of course!) even for subclasses of dict itself!
Look a the flash.utils.Proxy object.
The Proxy class lets you override the
default behavior of ActionScript
operations (such as retrieving and
modifying properties) on an object.
In AS3 you can code explicit variables accessors.
Example Class1:
private var __myvar:String;
public function get myvar():String { return __myvar; }
public function set myvar(value:String):void { __myvar = value; }
Now as you create an instance of Class1 you can access __myvar through the accessor functions.
if you want to set bindable that var you have to put the [Bindable] keyword upon one of its accessors.
Further, you can also implement the getter or the setter only, so your var will be read or write only.
I hope it helps.