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.

package {
   public interface ISingleton {
      function get someName():String;
      function set someName(value:String):void;
      function doSomething():void;
   }
}

So, for this example, it is quite small and understandable, i guess. Next thing, i implement the Singleton and i implement a SingletonFactory, both in the same file, that’s why i was talking about private classes:

package {
   public final class SingletonFactory {
      private static var _singletonInstance:ISingleton;
      public static function getInstance():ISingleton {
         if (_singletonInstance == null) {
            _singletonInstance = new PrivateSingleton();
         }
         return _singletonInstance;
      }
   }
}

class PrivateSingleton implements ISingleton {
   private var _someName:String;
   public function get someName():String {
      return _someName;
   }

   public function set someName(value:String):void {
      _someName = value;
   }

   public function doSomething():void {
      trace("Doing something with: " + _someName);
   }
}

So, as you can see, the PrivateSingleton is a private class, declared outside of the package definition, so it is only visible to SingletonFactory, no one else. PrivateSingleton, of course, implements ISingleton. And the SingletonFactory does, what Singletons normally do for themselves, it manages and creates the Singleton. I like that approach, because the responsibilities are separated nicely, the PrivateSingleton doesn’t actually know, that it is a Singleton. Should you ever decide to let it be a normal class, then you simply could put it into its own class file and things would still work, even for the SingletonFactory (although you probably would want to discard it then).

So, to use a Singleton like that, you would do something like this:

var mySingleton:ISingleton = SingletonFactory.getInstance();
mySingleton.someName = "Hans";
mySingleton.doSomething();

Well, that’s it, nothing big, just one more solution for building a singleton. One additional advantage here is, that you get nice compile time errors, when trying to use PrivateSingleton inappropriately. Most AutoCompletions will not even propose the class. Drawback is, you cannot inherit from PrivateSingleton and you still might have that dim feeling, that using private classes might be wrong.

The application in question is one, that has a very rich user interface with animations, video, sophisticated controls and so on. The domain model that lies behind all that is rather simple though. It is one of those applications in the advertising industry, that is more about the show than about utility.

I would roughly estimate, that 60% of the code that my colleagues will write is related to the UI and the rest goes for the model and the general application logic. Actually most of the applications we develop are partitioned that way. That’s nothing to get excited about, after all we’re building thin clients and of course a thin client is mostly made up of ui code.

But knowing that, i come to ask myself, why we are actually so excited about MVC, Domain Driven Design, architectrual frameworks, IoC and stuff. For the particular type of flash applications that we build, we should be more concerned about how to structure the V in MVC than about the whole MVC in general. That’s not to say, we should not care about general architectural matters, but being a flash developer, who is building rich user interfaces, we should rather think about structuring our views than about structuring our model, since in many cases, our model is not the core of our problem, but the view is.

Screenshot of the eco zoo campaign.

However, i do see too little articles covering this topic in particular. I also do not see enough design frameworks trying to deliver support in that area. Of course, we have frameworks, that aim at simplifying building UIs, such as the Flex framework. But for me, these frameworks rather try to look at the UI to be something, that should be made easy, so you don’t have to think about it to deeply, so that you can concentrate on the application itself. But what, if the presentation is the thing, you want to concentrate on? That’s why i’m so sceptical about tools like Adobe Catalyst, because i have the feeling, this tool tries to hide away the problem of developing complex UIs, suggesting that the act of architecting and developing a rich UI is something, that can be somehow automated and hidden behind a clickable tool. I strongly believe, this is not possible. It takes experienced UI developers to build stunning presentation layers and these experienced developers should start thinking about effective ways of building those UIs.

Screenshot of the ikea wardrobe solutions campaign.

I think it is time, that we think more about the underlying patterns in the development of rich and animated UIs. A discussion about those should not only be about components, because really rich UIs are not solely made out of classic components. Of course, in a sense you can define everything to be some sort of button, but i feel that doesn’t live up with what we really need. Especially as we are heading to UIs, that are try to go away from classic form style in favor of more integrated, chromeless UIs. Also we need to incorporate timing in a more fluent way. We already have some very good state patterns yet, but my feeling is, that todays UIs go beyond simple state, our concern is not so much the state, but the transitions. And sometimes UIs are constantly transitioning, so that one might start to doubt, if it is even useful to talk about states anymore.

To make a long story short, i think with the advent of rich, interactive and animated UIs we need a deeper discussion about how we can build those in an effective way, that allows for the basic principles like extendability, maintainability and reusability.