a little quiz again. We have three classes:

The first one is the main class of our swf, InternalTest:

package {
 
   import flash.display.Sprite;
   import testPackage.PublicClass;
 
   public class InternalTest extends Sprite {
      public function InternalTest() {
 
         var publicClass:PublicClass = new PublicClass();
         var ref:Object = publicClass.returnInternalClassRef();
         ref.doSomething();
         ref.doSomethingInternally();
      }
   }
}

Ok, in a package “testPackage” we have two other classes, PublicClass and InternalClass.

package testPackage {
   public class PublicClass {
 
      public function returnInternalClassRef():InternalClass {
         return new InternalClass();
      }
   }
}

package testPackage {
   internal class InternalClass {
 
      public function doSomething():void {
         trace("InternalClass did something!!");
      }
 
      internal function doSomethingInternally():void {
         trace("InternalClass did something internally!!");
      }
   }
}

Now make a guess, what happens?

Well, it’s not too hard to figure out, right? But interesting to remember anyway. The call for doSomething() works, whereas the call for doSomethingInternally() ends up in an exception. So if you define an internal class, you can still pass its reference outside its package (loosing the type obviously). Any public methods can be called then, but internal methods not. Makes sense, does it? I was just thinking about it, because i asked myself, why one would declare a class internal, but still have public methods.

So it only makes sense, if you want to pass it around as either an untyped reference or as a casted interface implementation. Means, you could have an interface outside the package and the internal class implements it. Then within the package you could use the class by its direct class type and outside you would use it by its interface type.

A commenter in a previous post said, he loves callbacks. That made me think about the difference and about why we mostly use events and not callbacks. I think one reason is, because the Flash Player is using events all over the place. But is using events always the best solution? I am not talking about performance here, i am more interested in the underlying concepts. Here’s a classification, i would like to propose( I have been searching the web for existing classifications. If you find one, please shout):

You should use a callback, when you’re client initiates an asynchronous call and awaits an answer to it.

Rationale

In Flash – as opposed to Java –  we are forced to do a lot of things asynchronously. The most popular example is loading a file. We as a client want to load a file and we want to be notified, when that process – the process, that we have initiated – is complete. We don’t want to be notified of loading events in general, no, we just want to know, when our initiated process has finished. A good way to detect a potential use case for such a scenario is, if you remove yourself as a listener in the event handler method. It is a good indicator, that you actually just wanted a callback.

The advantage of callbacks here is, that your intention becomes directly visible. If your calling a method, which takes a callback function, it is crystal clear, what is happening. You’re doing an asynchronous call and you are waiting for THAT call to finish. With events, you often have the problem, that the line in your code, where you added yourself as a listener, and the line in your code, where you are initiating the asynchronous call, might be in completely different places, which makes it hard to understand for another developer.

With callbacks, you have everything in one place and you can even check at runtime, that the callback is indeed a function and not null. You cannot check at runtime, if a client has added himself as a listener for a particular event before calling a specific method.

You should use events, when something can happen unexpectedly

Rationale

There are scenarios, in which you as a client have not initiated an asynchronous process by yourself, yet something still might happen. As an example, let’s consider an application with a shared model and different modules, that consume and feed it. ModuleX might want to be notified, when a particular value in the model changes. Yet, ModuleX might not do anything to force that. Instead another Module is doing something, that changes that particular value. Then the model dispatches an event, saying that the value has changed.

So in this case, the event comes unexpected for ModuleX. Unexpected, because ModuleX has not initiated an asynchronous process, which led to this event. ModuleX might have been idle for some time and now the event comes in and it lets ModuleX do, whatever it wants to do in that case. You cannot use a callback in this scenario, because the client didn’t want to start a process. Instead it really just wanted to be notified more generally, when something happens.

Another very popular example, where events make sense, is user interaction. You create a button and wait for a user to click on it. But the button does not force the user to click on it as part of a sequential process. Instead, the button just waits, until it might happen (which might be never). A callback would not make sense here.

say, you have a swf file, that contains some functionality, that you want to use in a main application. Roughly, this functionality will consist of an interface (by which in this case i mean a bunch of classes, which make the functionality public to the client classes) and the internal implementation (a bunch of classes behind the interface, which do the real work).

In a modular world, it would be nice to have the implementation be separate from the interface. In fact, so separate, that you could exchange it at runtime, if you wish to do so. So to be concrete, it would be nice, if the interface classes would be loaded into the main ApplicationDomain, so that everybody can use them and that the implementation classes would be loaded into a child ApplicationDomain, so that i could exchange them at runtime, if i want to.

No problem, you say, make two swf files. One with the interfaces, one with the implementation. Bahh, i answer, because i don’t want to spread my module over two swf files.

The solution is: Frames! The idea goes like this:

1. You create your interface classes (again, these are not necessarily just interfaces, might also be some classes). You will also want to create some kind of factory or facade, which will create the real instances and decouple the implementation from your interface. Within the facade or factory, you have to use getDefinitionByName(…)  to reference the implementation, because you don’t want your implementation to get compiled into this frame. The facade will be the only place, where the implementation is indirectly referenced. The interface should have no references to the implementation (why would it anyway?!).
2. You create your implementation. The implementation can have references to the interface, of course. Probably mostly in the form of inheritance, or interface implementation and of course composition.
3. Now you build your swf, either using the -frame compiler option or the Frame Metatag. Make sure, that the facade/factory and the interface compiles into the first frame and the implementation compiles into the second frame. It would make sense, that the Facade/Factory is actually the main class for your swf, so it has to extend MovieClip. This main class has to make sure, that it stops at the first frame, once the swf is loaded. Very important!
4. Now, in your main application, you need to implement some loading logic, that actually does the magic.
5. You load the swf from above into the main ApplicationDomain by using ApplicationDomain.currentDomain. Since the swf stops at the first frame, only the classes from the first frame are now available to your application. These are: The factory/facade and the interface classes.
6. Now you load the same swf a second time, but not using Loader.load(…), but instead using Loader.loadBytes(…) in conjunction with Loader.contentLoaderInfo.bytes. And this time, you load it into a child ApplicationDomain, using new ApplicationDomain(ApplicationDomain.currentDomain). This way, the whole thing goes faster, and you don’t have to actually make a new request over the net.
7. And now, you tell this newly loaded swf to go to second frame, which makes the implementation classes available (Since it started in the first frame, the facade/factory and interface classes are also loaded again, but they will be ignored this time, because they already exist in the main ApplicationDomain). But now the implementation classes are only available in the child ApplicationDomain.
8. Make sure, that you never go to the second frame in the first loaded Loader (you might want to nullify it, so you don’t accidentally do it). Because then, the whole benefit would be lost, because the implementation then would also exist in the main ApplicationDomain.

That’s it. This way, you can now unload the implementation and load a new one, if necessary. The facade/factory and the interfaces will stay. Which brings up a little catch: If you want to exchange the implementation successfully, you have to make sure, that class paths are always the same in the different implementations, otherwise, the facade wouldn’t work, of course. You could circumvent this, if you put the facade into the implementation frame as well and let some generic mechanics in the main application do the fetching.

Testing this, by the way, i found that jumping to a frame three (with gotoAndStop(3)) always introduces the classes in a frame two as well. Which is a pity, because otherwise you would have been very flexible in deciding, which classes you want to put in which ApplicationDomain.

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.

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.

i already wrote about this a while ago, but now i have filed a feature request in the bug base of Adobe. I want const fields allow for being initialized in the constructor, too, not only inline. Here’s, what i wrote in the ticket:

hello,

in the AS3 specification it says:
“A variable declared with the const rather than the var keyword, is read-only outside of the variable’s intializer if it is not an instance variable and outside of the instance constructor if it is an instance variable. It is a verifier error to assign to a const variable outside of its writable region.”

This implies, that a const can be initialized in the constructor, but in fact, it cannot, when in strict mode.

In the past, there have been at least two bug reports around this, with slightly different outcome. An early report (ASC-351) seemed to state, that it should be possible to initialize a const in the constructor. Unfortunately, from the report it is unclear, if strict mode was involved or not.

Another report later (ASC-3562) stated, that it would only be possible without strict mode.

I do think, that const initialization should be possible in the constructor, like the AS3 specification suggests, even in strict mode. It would make the whole const concept more useful. For example, declaring a const in a superclass and giving it a value inline currently means, that in subclasses you cannot give it a different value, because you cannot re-declare the field and you cannot give it a different value in the constructor.

Also, you might want to do some checks to decide which value to assign to the const, which you could do in the constructor based on parameters or other factors.

From my point of view, adding the ability to initialize a const in the constructor in addition to do it inline as currently possible, will not break any existing code, since it just adds new functionality, but does not change or take away existing functionality (besides not throwing a compile time error anymore).

So, what do you think? Do you agree? If yes, please vote for the feature request in the bug base. Otherwise, i still would be interested to read your opinion, of course

after all this thinking about not saving code as text anymore but in an object structure, i thought it might be worthwhile to understand a bit more about how ActionScript is built and what the elements are. What else to do but to dive into the specifications of ActionScript and the AVM2. Specifically i was interested in the abc file format, nicely described in the PDF from Adobe: “ActionScript Virtual Machine 2 (AVM2) Overview“.

Only problem was, it’s a lot of text and i usually can understand things better, if i see them visually. So i thought, it might be a good idea to make a diagram out of the textual description. So here it goes. I used Enterprise Architect to draw this, a very nice UML editor, by the way.

[Update]: I changed the format to PDF for better reading and printing.

I admit, there are still quite a lot of lines cutting across each other and making the whole thing still a bit hard to overlook, but hey, it’s a first version.

Perhaps this might come in handy for you, too, so i am posting this. Should you find mistakes in the diagram, a comment would be appreciated.

shame on me for thinking – even just for a second – i could have been the first one with this idea. Of course not . As commenter Ben pointed out, there are thoughts about this subject already and they exist for some time now.

There is Intentional Programming. IP has a lot more in it than just the fact, that is proposes to have an abstract representation of code be stored instead of concrete code in text files. But the abstract representation seems to serve as a kind of basis for the whole thing. Intentional Programming is brought forward by Intentional, who are working on a software development system around the ideas of IP. They did a presentation on the DSL DevCon 2009, which is a bit lengthy, but nevertheless awesome. Martin Fowler also wrote down some thoughts on Intentional and their solution.

Then there is SOP and a tool in early alpha stage. Can’t say too much about it, as the guy is a Russian and Google Translate does not a very good job at translating from russion to german

And lastly, there is another good article from Martin Fowler on the subject in general, which goes way beyond, what i am currently thinking about. Means, i am still at the stage of technical ideas and he is already taking the whole thing into the business world as well as Intentional does.

All this is truly inspiring. Would love to see something like this for Flash, i think it also could be the answer for true designer / developer collaboration.

there is a topic i’ve been thinking about lately, which is source code and the way we store it currently. Specifically, i do wonder, if storing source code as text is still the right way. Especially for languages, which are not run in an interpreted way, but compiled or pre-compiled i wonder, why we actually store that code in text files.

If you look at all the tools we use, the IDEs, the compilers, UML modelling applications. All these tools currently take textual code and transform it into intermediate object structures, with which they work. Take code highlighting. For being able to have proper code highlighting, tools have to parse the text, understand the very basics of the structure of the code in order to do the highlighting.

Take code completion. The tool has to parse the textual source code into some kind of object structure in order to understand, what references, functions or objects to offer.

Take refactoring. The tool has to parse the textual source code into an object structure in order to change namings, move functions into different classes while updating the references and organizing imports and so on.

Take UML reverse engineering. The tool has to parse the textual source code into an object structure in order to build the represented class hierarchy that serves as the basis for visualizing that hierarchy in UML. All these tools work with object structures or syntax trees rather than with the text itself. Alle these tools have to parse the text over and over again.

In the end, that’s also, what the compiler does before it transforms the whole thing into binary instructions. So, i ask myself, wouldn’t it be more efficient to actually store the source code in some kind of object structure, so that these tools can make direct use of it instead of having to parse it again and again?

Googling this subject (i was not even sure, what to search for, because i couldn’t decide on good search terms), i only found one wiki article, that discussed that topic a little bit, but differently, as that the people there thought about storing source code in databases, which i am not so sure, whether this is the best way. But the thoughts behind that go into the same direction.

I understand, that storing source code in text files has some significant advantages, the most obvious being, that everyone can read text files, because it is so standard and minimal. Also, source code repositories make use of text and can handle it very intelligently.

But i think, since software applications today become more and more complex, wouldn’t development environments, that handle source code as object structures from the very start, be capable of handling that source code more efficiently and even more intelligently? If we would start thinking about source code as being a model and a textual representation of that model simply being one view (UML being another), wouldn’t that provide completely new possibilities for IDEs and the whole ecosystem of software development? In respect to MVC, doesn’t source code stored in text files currently strongly couple the model with the view, something we normally try to avoid as hard as we can? Things like indentation, the use of braces or brackets, specials keywords, semicolons and blank lines, aren’t these just visual decorations, either in order for us to be able to read the code or for the parser to parse it? Imagine, how code could look like, if we wouldn’t need those things, because we wouldn’t need a text parser.

Have you found articles on that topic? Would be curious to see them.

this post was inspired by a topic, i am interested a bit lately, “Functional Programming”. There is a very informative series of videos over on channel9, that covers functional programming, moderated by Erik Meijer from Microsoft Research. I have not yet made it through every bit of the topic, but one thing, that has already made a big impression on me is the statement, that functional programming emphasizes honesty of code. So what does that mean?

Honesty means, that a developer wanting to use a method for example, exactly knows, what to expect from it. In some sense, ActionScript has some limited honesty. Let’s take this method for example:

var names:Vector.<String>;
 
function getName(id:int):String {
   return names[id];
}

It seems to be honest about, what it returns, a String (we will see, it isn’t really honest about that). But it isn’t honest about what String. We could call this method three times with the same value for ‘id’, but we could not be sure, that we allways get the same result back, because the return value depends on the stuff, that is in the ‘names’ Vector. This is called side effect. Functional programming tries to avoid side effects where possible. The aim is, whenever i give a specific value to a method, i should get back the same result. So the method is not only honest about the type of value, but also about the value itself.

OK, so far, so good. So what’s that to do with errors in ActionScript? Let’s look at the method again from above. If you try to use a Vector with an index out of the bounds of the Vector, you get a RangeError. By the way, i was astonished to recognize, that trying to do that with an Array simply returns null, while Vector throws an error. I find that to be a bit inconsistent. Anyway, what that means is, that our method getName()  could potentially throw an error instead of returning a String, as it declares. This might sound trivial, but i find it to be absolutely non-trivial. Strict typing means, that i as a programmer can expect, that if the method says, it returns a String, it will do so. But now we find, that it might not. getName() might not return anything, if an error occurs. Now you might reply “well, simply catch the error, and you’re good”. But how am i to know, that i have to? If i am responsible for the whole code base, i might know, that this method can throw an error, but what if the method is provided by some third-party library?

So this means, that ActionScript is not completely honest about return types, because we can only hope, that a method returns, what it says, but it might as well do nothing. Java tries to circumvent this problem with the ‘throws’ clause. A method can define, that it either returns what it returns, or that it might throw an exception of a certain type. The point here is, the Java compiler will not compile a method, if it finds, that the code in that method might throw an exception, but that the method has not either catched it or declared via the ‘throws’ clause, that the exception might occur (there are exceptions to this rule, but let’s just forget about these for a moment).

We don’t have that in ActionScript. In ActionScript, any method could potentially throw an error (not to speak of error events, which enlarges the problem even more) and we simply have no chance of knowing which method might throw which error. In the light of these thoughts it comes to no surprise, that the new flash player now supports global error handling, which for me feels like fixing a sympton rather than the cause. Catching errors globally is just another way of saying: “I have no idea, where all these errors come from, so let me simply catch them all in one place.”

To end up with, i want to repeat, that Array simply returns null, when trying to use it with an index out of the bounds of the Array. So it does not throw an error like Vector does. Looking at it from a functional-programming-point-of-view, this is more honest, than what the Vector does. If i would have made my example with an Array, getName() would allways return a String (well, not really, but null can be implicitly converted to a String by the runtime, so … it’s OK). That means, that the programm does not break and the contract is valid, the method is more honest. Of course, now you might have to deal with checking for null, as Jesse Warden complaint about already. A solution to this problem could be to return a default value instead of null. Of course, this will not work in all situations.