Juten Tach,
i am currently porting some code from Java to ActionScript. And of course, doing that makes some differences between these languages directly visible. One thing for example is: getter/setter methods. I love the ActionScript getter/setter approach. I think, it is pretty well-thought-out. The good thing about it is, that they look like a property. Which has the nice benefit, that in ActionScript you can always start with a public property first and change it to getter/setter, if you want to do something during assignment or return, or if you simply want to prohibit assignment. This is completely different to Java, where the rule of thumb is to always use getter and setter methods in the first place. Which makes absolute sense there, because getters have a different appearance to a client than properties.
Now, since getters and setters are so different in ActionScript compared to Java, i think, Interfaces in ActionScript should also look different, at least for some details. The job of an interface is to describe how to use an object. It should not describe, how the object implements functionality. Thus in Java only methods are allowed to be defined in an interface (and static properties for some reason). Which makes sense, because for accessing properties, in Java you would certainly use getter and setter methods.
ActionScript is different though. And that’s why i think, in ActionScript it should be allowed to define properties in an interface and let an implementing class decide, if it implements these properties using a real public property or getter and setters. Only if you want implementing classes to implement a read-only property, you would add the “get” keyword to the definition in the interface. So, an interface, that would want to define a property that is read-write enabled, could look like this:
interface Something { var myPublicField:String; }
And a class implementing that interface could start with implementing that field with a simple class variable, OR by using setters and getters, like so:
class Someone implements Something { var _myPublicField:String; public function get myPublicField():String { return _myPublicField; } public function set myPublicField(value:String):void { if(everythingIsOK) _myPublicField = value; } ... }
And an interface wanting to restrict the field to read-only could add the “get” keyword:
interface SomethingReadOnly { var get myPublicField:String; }
Note, that i am not so focused on the concrete notation here. Probably there could be better ways to notate these things. The point is, currently the only thing you can do in an interface is to define getter and setter functions, which automatically means, you have to implement them, even if a public property would be sufficient for a start. So the interface in fact defines the way to implement the field, which it shouldn’t.
Juten Tach,
if you’re looking at the upper right corner of this blog, you will notice, i am not working for Interone anymore. Nope, i am now working as a freelancer. After six and a half years it was time to start a new chapter. And that means, i’m more involved in coding again than before, which is good, because that was the plan.
And being here, i already got stuck with some specialties of good old Flash again.
I am currently investigating on how close one can implement the OSGi specification in AS3. I don’t want to get into too much detail about OSGi here, only so much: We’re talking about modules, that have dependencies to other modules. My thinking is, if ModuleA has a dependency to ModuleB, then ModuleB doesn’t necessarily have to know something about ModuleA, right? In fact, it would be nice, if ModuleA would be hidden from ModuleB, so that it cannot accidentally break something.
So i thought, hey, ApplicationDomains. If ModuleA is loaded into a child ApplicationDomain of ModuleB, then ModuleA has access to everything from ModuleB, but ModuleA is still hidden from ModuleB and cannot accidentally break something, because classes from ModuleA are not made directly accessible to ModuleB. Great.
Or not so. It is not uncommon, that one Module has more than just one dependency. So now let’s assume, ModuleA is not only dependent on ModuleB but also on ModuleC.
Yes, do it, think …
It doesn’t work, right? Since ModuleA is already loaded into a child ApplicationDomain of ModuleB, that same instance of ModuleA cannot also be loaded into a child ApplicationDomain of ModuleC, because an ApplicationDomain can only have one parent.
That alone means, one will never be able to implement the OSGi specification closely, because the only solution would be, to load everything into the main ApplicationDomain, which means, that you cannot completely unload (or uninstall, as OSGi puts it) a module again, because the class definitions would always stay (different to child ApplicationDomains, where the class definitions go, if you unload the respective swf).
Too bad.
[Update]: A colleague just pointed me to another issue: If you have a scenario like this:
Main ApplicationDomain -> child ApplicationDomain -> grandchild ApplicationDomain
[Update 2]: Oh man, sometimes a little bit more investigation would be advisable. Accessing a grand parent ApplicationDomain DOES work, it only needs code free of bugs … ![]()
Thanks senocular!
Juten Tach,
lately i came across the || operator again and i read through the language specification. Little quiz: What is the content of the variable result in this line of code?
var result:* = null || "one" || "two";
The answer is: “one”. As for me, i had forgotten, that the || operator actually returns the value, that evaluates to true. If both values evaluate to true it returns the one on the left first.
So i started to think about, how to make use of this and the Chain of Responsibility Pattern came to my mind. You remember this pattern, right? You have a list of classes, that have different capabilities and you have a task. Instead of finding out by yourself, which class to use, you simply pass it to a chain, where these classes are connected. Each class determines for itself, if it is responsible and the first one, that answers with yes, is returned and gets the job.
So here i present a little exemplary implementation of a Chain of Responsibility, that in its core makes use of the || operator. By the way, i am not really conforming to the original pattern, because i actually don’t like it. In the original pattern, the potentially responsible classes link to each other directly, which in my opinion causes some trouble. First, they have to be aware, that they are part of a chain, which i think, they shouldn’t and second, they define the order in the chain themselves, which i think they shouldn’t and third, the requesting class has to know, which one is the first class in the chain, which i think, it shouldn’t.
[Caution]: This post now gets a bit lengthy
To build this Chain Of Responsibility thing, we need four ingredients: a chain, some potentially responsible classes, a request that should be processed and finally a using class, which wants the request to be processed.
We start with the request. For this example, it is really simple:
package responsibility { public class Request { public var stuffToBeProcessed:*; } }
As you can see, there is just a variable, which holds some kind of value, with which we want to work with. I did not give it a type to make it more interesting at runtime. You will see later on.
OK, next we need some classes, which can handle this type of request. Therefore we define an interface, which describes this general ability.
package responsibility { public interface Responsible { /** * Checks, if this class can handle the request. * @return An instance of Responsible or null. */ function checkResponsibility(request:Request):Responsible; /** * Processes the request. */ function doIt():void; } }
Pretty easy, right? The checkResponsibility(request:Request) method will either return itself, if it feels responsible for the request or null. The doIt() method then will actually do, whatever is to be done for fulfilling the request.
Next, we have two concrete classes, which implement this interface, ResponsibleOfStrings and ResponsibleOfNumbers:
package responsibility { public class ResponsibleOfStrings implements Responsible { public function checkResponsibility(request:Request):Responsible { if(request.stuffToBeProcessed is String) { return this; }else return null; } public function doIt():void { trace("ResponsibleOfStrings is doing it!"); } } } package responsibility { public class ResponsibleOfNumbers implements Responsible { public function checkResponsibility(request:Request):Responsible { if(request.stuffToBeProcessed is Number) { return this; }else return null; } public function doIt():void { trace("ResponsibleOfNumbers is doing it!"); } } }
So, you can see, these classes simply check if the request holds a string or a number respectively. If they find what they expect, they return themselves, otherwise they return null.
OK, next we need a chain. Very well, here it is:
package responsibility { public class ChainOfResponsibility { private var listOfResponsibleObjects:Vector. = new Vector.; public function addResponsibleObject(responsibleObject:Responsible):void { listOfResponsibleObjects.push(responsibleObject); } public function determineResponsibleObject(request:Request):Responsible { var result:Responsible = null; for(var i:int = 0; i < listOfResponsibleObjects.length; i++) { result ||= listOfResponsibleObjects[i].checkResponsibility(request); } return result; } } }
So finally here comes the part with the || operator. We run a list of potentially responsible classes. And in the function determineResponsibleObject(request:Request), we now go through this list. And here we make use of the fact, that when we chain the return values of each checkResponsibility(request) call by using the || operator, we get the first one, that returned itself instead of null. Means, we get the first class instance, which feels responsible for doing the job.
OK, lastly of course, we want to see, how to use that stuff. So here it is:
package { import flash.display.Sprite; import responsibility.*; public class Main extends Sprite { public function Main() { var chainOfResponsibility:ChainOfResponsibility = new ChainOfResponsibility; chainOfResponsibility.addResponsibleObject(new ResponsibleOfNumbers); chainOfResponsibility.addResponsibleObject(new ResponsibleOfStrings); var request:Request = new Request; request.stuffToBeProcessed = 10; var responsibleObject:Responsible = chainOfResponsibility.determineResponsibleObject(request); responsibleObject.doIt(); } } }
So, first we are setting up our Chain of Responsibility an give it our two responsible classes. Then we build a new request. In this case, we assign a number to the variable stuffToBeProcessed. Then we hand that request over to our chain and save the result in our variable responsibleObject. Finally we call the doIt() method on that object. And if we run this, we get a trace saying “ResponsibleOfNumbers is doing it!”, as expected. Of course, if we had assigned a string to the variable stuffToBeProcessed, than we would have seen “ResponsibleOfStrings is doing it!”.
Well, that’s it. If you find this useful, you can use it freely for any purpose.
Juten Tach,
it is a common procedure for me to visit the websites of the people, who leave comments on my blog. And what can i say, this time it payed off very well. On http://actualwave.com/blog/ (caution: this one is in Russian), after some Google Translation, i could find two very interesting links to tools for Actionscript:
- UML4AS is a UML editor plug in for Eclipse, which directly syncs with your ActionScript code and vice versa. Still alpha, but already very promising.
- Realaxy is actually, what i am thinking about for some time now. It is an Actionscript editor based on the MPS editor toolkit from Jetbrains, which means, it is based on an abstract syntax tree, instead of code text files. So far, there are only screencasts to watch, but still, very, very interesting.
Juten Tach,
i work with Actionscript for some time now, but i wasn’t aware of that little thing. You can use “in” for checking, if an attribute/field exists in an object, like so:
package { import flash.display.Sprite; public class Test extends Sprite { public function Test() { var myObject:Object = {name: "foo", nothing: "bar"}; trace("name" in myObject); // true trace("anything" in myObject); // false } } }
It also works for checking for fields in class instances. Might come in handy sometime
