new operator to create an instance of the Object class. For example:
var techWriter:Object = {fname:"Francis", lname:"Cheng", company:"Adobe"};
]]>
In ActionScript 3.0, you can use object initializers exclusively with the Object class. Once this new feature of ES4 gets rolled in to ActionScript, however, you will be able to use object initializers with other classes. Here's how it will probably work: place a type annotation after the closing curly brace. Let's say I have a simple class named Employee:
class Employee {
var fname;
var lname;
var company;
}
With ECMASCript 4, I'll be able to create an instance of Employee using an object initializer:
// ECMAScript 4th Edition code
var techWriter:Employee = {fname:"Francis", lname:"Cheng", company:"Adobe"}:Employee;
One thing to keep in mind is that this will only work if all the fields of the object literal are of the form "fieldName:value". So what's the point of including this capability? The rationale comes from the idea of "evolutionary programming", which refers to the idea of moving from a more informal, scripting-based way of programming to a more structured and formal way of programming. Say you start with a simple script that provides rudimentary interactivity on your web page. As time goes by, you may decide to add more features to the script. At some point, you may find that the script is getting so complex that some formal structure would help. The idea of evolutionary programming is that the language should help you transition from the informal style to the formal style.
Type annotations on object initializers is an example of a feature that facilitates the transition from informal to formal programming style. In the example above, you can see how I moved from using a simple instance of the Object class to the more formal structure of an Employee class. Another feature that helps with this type of transitional programming is structural types, which allows you to create an simple type without creating a class. To give you a better sense of what evolutionary programming means, let's step through the transition again, but this time with a structural type thrown into the mix.
First, I start with an instance of the generic Object class:
var techWriter:Object = {fname:"Francis", lname:"Cheng", company:"Adobe"};
Second, I decide to get a little more formal by creating a structural type to represent employees:
// ES4 structural type definition
type Employee = {fname:String, lname:String, company:String}
Third, I can now create instances of the Employee type with an object initializer or with the new operator:
// ES4 object initializer
var techWriter:Employee = {fname:"Francis", lname:"Cheng", company:"Adobe"}:Employee;
// ES4 new operator can be used with structural types
var techWriter2:Employee = new Employee("Francis", "Cheng", "Adobe")
Finally, I can replace the structural type with a class:
class Employee {
var fname;
var lname;
var company;
}
So both structural types and type annotations on object initializers provide flexibility in the transition from using plain Object instances to instances of a class. For example, after I define the Employee class, there's no need for me to rewrite the instantiation code I wrote in step three because the code works for both the structural type and the class.
Here's a list of relevant links:
]]>You may have used object initializers in ActionScript 3.0 before. They provide an easy way to assign a literal value to a variable of type Object. For example, in ActionScript 3.0, you may see something like:
]]> This creates an object calledmyObj with two dynamic properties, name and color. The properties are dynamic in that they are not defined as part of the Object class and can be deleted at runtime. For example, the following code deletes the name property:
In ActionScript 3.0, if you want to ensure that the name property cannot be deleted at runtime, you have to define a class and make name a member, or "trait", of that class. In ActionScript 3.0, a trait is a class member that cannot be deleted at runtime. In ECMAScript 4, traits are called "fixtures", but you don't have to create a class definition to create a fixture. In fact, you can create fixtures with object initializers. For example, let's say you want to make the name property a fixture, so that runtime code cannot delete the property. In ES4, you'll be able to do this:
What if you want both name and color to be fixtures? All you have to do is place the "var" keyword before the curly braces. Doing so will make every property you name a fixture, like so:
The fun doesn't stop there, though. Let's say you like creating objects on the fly like this, but that you'd want each object to have a unique ID number property that not only is a fixture, but also is a constant (i.e. read-only). All you have to do is use the keyword const instead of var:
You can also use the const keyword before the curly braces if you want to make all of the properties you name read-only fixtures.
Here's a list of relevant links:
"...(news flash) proper tail calls are out of ES4 as of yesterday's Ecma TC39 meeting, by general (regretful, in Mozilla's case) agreement."
It's not in the meeting notes yet, but I'm sure it will be added before the meeting notes are finalized. I guess the writing was on the wall, because the only three companies that have commented on this feature have all marked this feature as a low priority in the ES4 Progress Tracking Spreadsheet.]]>
Yet another set of columns in the spreadsheet indicates the current thinking of several companies that participate in the ES4 working group. It uses color coding to indicate whether a particular feature is high or low priority for a given company. So far, Adobe, Google, Mozilla and Mbedthis have filled out these columns. Apple has indicated that they will have their column filled out by the end of the week. These columns are not binding in any way, but will be used to inform further discussions about the various proposals.
Here's the link to the ES4 progress spreadsheet again, in case you missed it at the top of the post:
]]>... (informally called "splat"), for ECMAScript 4th edition. The fate of this ticket is currently unknown, but I really like this proposal because it solves a thorny issue I've had when trying to pass ...rest arguments to a super constructor in ActionScript 3.0. I'll get back to that problem in a minute, but first I want to draw a clear distinction between the proposed ... (splat) operator and the ... (rest) parameter that many of you have probably used in ActionScript 3.0.
]]>
In case you don't know, ActionScript 3.0 has a ... (rest) parameter that you can use to specify that a function accepts a variable number of arguments. For example, the Array.push() method uses the rest parameter to signify that it accepts a comma-separated list of arguments:
The ... (splat) operator complements the rest parameter by allowing you to send an array of values as arguments to a function when you don't know ahead of time what the length of that array will be at runtime. In other words, you use the rest parameter when you define what a function will accept as arguments and you use the splat operator when you are actually sending arguments during a function call. Now let's take a quick look at the major use case that the splat operator addresses.
Let's say you have a base class with a constructor that uses a rest parameter. You then create a subclass with a constructor that also uses a rest parameter. How do you pass the arguments from the subclass's constructor to the superclass's constructor? Let's see what happens when we do that:
Note that in the constructor for Base, I trace only the first element of the args array. When I create an instance of Base and pass in the list of numbers 1, 2, 3, the constructor converts the arguments into an array of three elements. However, when I create an instance of Extender with that same list of numbers, they end up bunched together as an array in the first element of the args array in the Base constructor. Unfortunately, in ActionScript 3.0 you cannot use Function.apply() to call the super constructor. There is currently no simple way in ActionScript 3.0 to pass through the arguments to the super constructor and have the arguments treated the same way whether they come from a direct instantiation of Base or through a call to super() from Extender.
The proposed ... (splat) operator solves this problem by allowing simple pass-through of rest arguments using the following new syntax:
Here's a list of relevant links:
]]>You like it so much, in fact, that you use it in many different situations. The only problem is that in ActionScript 3.0, you can't easily use strong typing to specify that a specific instance of List should contain only a certain data type. You could extend List, I supppose, and create a ListOfIntegers class, a ListOfStrings class, etc., but that can get hard to manage if you use it for more than just a few different types.
The type parameters feature, however, makes strong typing of collections much easier. If you saw my previous post about Vectors, you've already seen type parameters in action because the Vector class requires them. But let's rewrite the List class using a type parameter:
What we've done is define List such that it is now a "list of some type", where the type is represented by the parameter "T". In other words, the class List.<T> is "generic" in the sense that it is not tied down to a specific data type, at least until you specify a type when you create an instance of the class. This means that we can use the parameter "T" inside our class definition as if it were a type. You can see in the declaration of the variable head that we used a type annotation of "T". When we later create an instance of the List.<T> class, the compiler will substitute the type we specify for every occurrence of "T".
Let's say I have a class called Employee and I want to create an instance of my List class that stores only instances of the Employee class. Here's what it would look like:
So you're probably wondering what's up with the funny syntax for type parameters. How did we end up with the syntax className.<Type> for type parameters? Well, the working group went through a long discussion about it, which you can read on the type parameters proposal discussion page at the ecmascript.org site.
One thing you may have noticed about the List.<T> class is that T can be any type. We passed in the type "Employee", but we could have passed in int, string, or any other built-in or custom type. There's no way in ES4 to limit, or in other words create bounds for, the types that you can pass in to for "T". Some languages with generics allow you to constrain the type parameter by setting up type boundaries. In other words, some languages allow you to specify a restricted set of types that can be used as typed arguments. For example, in Java you can define a class that takes a type parameter that must extend another class, so you could say class List<T extends Employee>, to get a List class that takes only subclasses of Employee. The ES4 spec does not require implementations to provide bounded type parameters.
Best way to explain this is through an example. Let's take that Employee class we talked about earlier and extend it with a new subclass called TechWriter. Clearly, TechWriter is a subclass of Employee, and can be safely used anywhere that Employee is used. But does that mean that List.<TechWriter> is a subtype of List.<Employee>? It turns out the answer is no. The ramifications of this can be seen in the following example, in which the function reprimand() takes a parameterized List as its parameter:
Calling the reprimand() function with a value of type List.<TechWriter> causes an error because the function is expecting the type List.<Employee>. Other languages use something called variance annotations to solve this problem. In this case, the error would go away if the subtype relationship of the two lists matched the subtype relationship of the types Employee and TechWriter. Such variance is called covariance. Java, for example, allows you to use wildcards to indicate that you want to allow covariance, something like <? extends Employee> would do it if you used that in the declaration of reprimand().
The type parameters proposal does leave open the possibility that variance annotations could be added in a later edition of ECMAScript. The proposal points to a journal article that proposes a variance annotation style that is simpler than Java's. If ECMAScript goes that route, you would be able to rewrite the function to support covariant type parameters with just one extra symbol (note the + symbol in the declaration of reprimand()):
Personally, I like the brevity of this style of variance annotation and hope that they adopt this for ECMAScript 5. The proposal lists a workaround, however, that purportedly mitigates the need for variance annotations. I have to say, though, that the proposed alternative is little intense for my taste, but hey, I'm just a tech writer. You can have a look at it and see if you like it better than using a variance annotation. Look for the code example that defines a class called Container.<T> on the type parameters proposal page under the section titled Variance Roadmap.
Here are some useful links I came across in researching type parameters. These deal mostly with generics in Java, C++ and C#:
After considering a few languages, the working group settled on Standard ML '97 and use a compiler/programming environment called Standard ML of New Jersey, or SML/NJ for short. That need not concern you, however, if you just want to play around with some of the new features because Dave Herman has created a set of binaries for Windows, Mac OSX and Linux that you can download from the ecmascript.org downloads area.
Here is Graydon's punch list of features that are in the "M2" build of the RI (from his original post to ES4-Discuss):
Implemented, may have bugs:
Implemented and partly working, but still in flux / work to do:
Partially implemented / not yet working:
Unimplemented:
In case you missed it above, here is a link to the downloads area of the ecmascript.org site if you want to download binary versions of the RI (The source code is also available on that page):
]]>The Vector class is is defined with the final attribute right now, which means that you cannot create subclasses. This could change, however, before the specification is finalized. The length parameter has a type annotation of uint, which means that the maximum vector size is 232-1 and the largest index value you can use is 232-2.
If you are familiar with ActionScript arrays, you know that they can have "holes" in them. For example, let's say you have an array that has three elements and the length property is 3. That's a "dense" array with no holes. However, I can write to an arbitrary index number and the array will automatically "grow" to accommodate me. For example, if I write to index 10, the length of the array will grow to 11, but the array will have a hole in it between index 3 and 9, inclusive. Or, you could look at it as having 7 holes, with each undefined element considered a hole. Having holes like this can really slow down the process of iterating through the array. Vectors, by contrast, are always dense. You cannot have holes in a vector. Every element of a vector is always defined.
So what happens if I have a vector with three elements and I try to assign a value to index 10, as I did with an array in the previous paragraph? The short answer is that you get a runtime error (a RangeError to be precise). In fact, this happens even you just try to read from that index, much less write to that index.
There is a little flexibility built in, however, for those who want to change the size of the vector. First, you can "grow" a vector by assigning to the very next available index. For example, if I have a vector with three elements (index positions 0, 1, and 2), I can directly assign a fourth element to index position 3. Second, I can alter the value of the length property to grow or shrink the size of the vector. For example, if I change the length to 11, I'll increase the size of my vector so that it contains 11 elements. This is somewhat similar to how the length property works for arrays, but the significant difference is that with vectors, all 11 of the elements are defined. Both of these techniques, however, work only if the fixed property is set to false.
You may have noticed that the second parameter to the Vector constructor function is a boolean named fixed. The default value is false, but you can set this to true either at construction time or anytime thereafter using the fixed property of the Vector class. Whenever fixed is set to true, any attempt to change the size of the vector will generate a runtime error, whether the attempt is made by assigning a value to the index number that is equal to the value of length or by directly changing the value of the length property.
You can use type parameters to designate that you want a "mono-typed" vector, which means that the vector can contain values of only one specific type. For example, you can define a vector that holds only integers and has a fixed length of 7 by declaring:
The resulting intVector vector will be constrained to values of type int.
The current plan is for the Vector class to have as many of the Array methods as possible. Vector will contain not only the traditional methods such as push(), pop(), slice(), sort(), etc., but also some of the newer methods such as every(), filter(), indexOf(), some(), etc. A complete list should be available soon on ecmascript.org.
This only scratches the surface of the new Vector class. Rest assured that there will be more to come about this new built-in class as we move forward with the draft specification. Here are some relevant links on the ecmascript.org site:
||=, &&=), a feature that is proposed for ECMAScript 4th edition, but is already implemented in ActionScript 3.0. To understand the rationale behind the Logical Assignment Operators, you need to understand how the logical operators in ECMAScript and ActionScript work. Most people think of these operators in purely boolean terms. In other words, if you have two boolean variables, conditionA and conditionB, you can use the logical operators to calculate logical results. For example, if one condition is true and the other is false, the logical AND operator returns a value of false because both conditions have to be true in order for logical AND to return true. ]]>
true in this case because it takes only one condition to be true for the logical OR operator to return true:
The logical operators are far more interesting than this, however, in that they are not limited to Boolean values. You can use other values as operands to the logical operators. For example, let's say you want to check whether values have been assigned to a pair of string variables. The result is true only if both variables contain string values.
But it gets even more interesting because the logical operators don't necessarily return a Boolean value. What's really going on is that the logical operator returns the value of one operand or the other. For example, the logical AND operator examines the first operand and if that operand is either false or can be converted to false, the operator returns the first operand and never even looks at the second operand. If the first operand turns out to be true, the second operand is returned. We can see this in action if we just change the type annotation of the variable bothStringsSet in the previous example to type String:
This is null because the value of the first operand, str1, converts to false, so the logical AND operator returns the value of str1, which is null
This is also null because even though the value of the first operand now converts to true, this just means that the logical AND operator returns the value of the second operand, str2, which is still null.
The logical AND operator does the same thing here as it did in the previous code snippet--it returns the value of the second operand because str1 converts to true, but we get a different value as a result because the second operand now has the value bar. That's not a very practical example, so let's look at something that makes a little more sense.
Many programmers use the logical OR operator to assign default values. The logical OR operator is the exact opposite of the logical AND operator. In other words, the logical OR operator returns the first operand if it is either true or can be converted to true, and otherwise returns the second operand. What does this have to do with assigning default values? Well, you only want to assign a default value if a variable is undefined, so you could write the following code to assign a default value:
Alternatively, you could use the logical OR operator to serve the same purpose:
If myVar is undefined, the logical OR operator considers that as false, so it returns the value of the second operand, "default". If myVar has a value assigned already, the logical OR operator considers that as true and just re-assigns the value of myVar to myVar. It's a matter of personal taste. Some argue that using the if statement is easier to read. Nevertheless, there are some programs that use the logical operator technique, so at the very least it's handy to know about it.
Finally, we get to the "assignment" part of the logical assignment operators. For those of you who find the logical OR technique for assigning default values distasteful because it's hard to read, you may want to stop reading now. I say this because a common technique among Ruby and Perl programmers is to use an even more abbreviated form of this technique that takes advantage of the logical OR assignment operator. In other words, the following code:
can be rewritten using the logical OR assignment operator:
There you have what I believe to be the most common use of the logical OR assignment operator. Examples of the logical AND assignment operator are less common, but one use-case could be to increment a variable, but only when that variable is greater than zero. For example, the following code increments myNum only if it is not zero:
As parting words, I should say that I'm not advocating the use of this technique, but I do think it's worth understanding because you may come across code that uses this technique.
]]>
First we start with a class that Gamma calls the "context", which in our case is a class I'll call TrafficLight. This class is sort of the "master" class that we'll use to represent the state machine. Second, we'll create an interface, let's call it IState, that contains methods that represent all the behaviors in our state machine. Well, in our case there's only one behavior, which is changeColor(). Third, we'll implement this interface with classes that represent each of our states. We'll have three classes: RedLight, YellowLight, and GreenLight, all of which will implement the IState interface.
For simplicity's sake, I'm just making my variables public and I'm ignoring the need for event listeners and a timer. Also, I'm including only the RedLight class because the YellowLight and GreenLight classes are essentially the same:
TrafficLight Class
IState Interface
RedLight Class
That's a lot of structure for a simple model, but the payoff is that you have a model that's easy to extend. For example, we could easily adapt this state machine to handle British traffic lights that have an extra state where red and yellow both appear. All it would take is a new RedYellowLight class and minor changes to the TrafficLight and RedLight classes. Now let's take a different approach that uses PTC.
When I mean different, I mean that we'll leave the nicely structured world of class-based programming and enter the wild world of dynamic programming. So turn off Strict mode and let's not worry about type annotations. If we have PTC at our disposal, we can use it to design a quick and easy state machine that uses a function to represent each state. It can't get much simpler than that. When it is time to transition to a new state we make a tail call to the appropriate function.
I added a variable named cycles to control the number of times the program runs. What's interesting is that if I set cycles to anything over 252, I get a stack overflow error. I'm only decrementing in the redLight function, so that means each decrement of cycles represents three functions placed on the stack. So the error appears after a little more 750 of those functions are placed onto the stack. Clearly, you wouldn't want to use this technique in ActionScript today, but if PTC becomes part of ActionScript, the stack overflow error would not occur because each tail call function would replace the preceding call on the stack. Of course, this is not necessarily a better way to implement a state machine, but it is an alternative that certainly has an appealing simplicity to it. It may not scale as well as the design pattern technique, but may come in handy for implementing simple games.
Here are some links to resources about state machines:
So let's call factorial() with an argument of 3 and walk through the code execution. The parameter num is assigned a value of 3, which means we skip down to the else{} statement because 3 is greater than 1. In the else{} statement, we call factorial() again, but this time with the argument value 2. When the new call happens, the runtime suspends execution of the original call to factorial() and pushes the original call onto the stack because we'll need it later. Next, we walk through the second call to factorial(), but with the value 2. We get similar results, factorial() gets called a third time, but this time with an argument value of 1.
At this point we've not yet returned from any function, so all of these functions are still active and piled onto the stack, with our initial call at the bottom of the stack. With the call to factorial(1), however, we finally enter the if{} statement and simply return the value 1. This means that the call to factorial(1) can be discarded and we emerge back inside the else{} statement in the previous call to the factorial function, factorial(2). This return trip back down the stack is where values are returned and the calculations occur:
Notice that the recursive call to factorial() is not in tail position because the last thing the function does is multiply num by the return value of factorial(num-1). So PTC would not affect the execution of factorial() as it is written above. To get the benefits of PTC, we would need to refactor the code so that the recursive call to factorial() is in tail position. One way to do that would be to use a helper function that handles the recursion:
PTC will apply to factorialIterator() because the recursive call to factorialIterator() is in tail position. The factorialEx() function takes a very different approach in that it uses a counter to track progress so that it doesn't have to fill up the stack with a large number of suspended function calls. A call to factorialEx() sets in motion a series of tail calls that keeps stack usage constant. Stepping through, a call to factorialEx(3) results in a tail call to factorialIterator(), which results in recursive tail calls until the counter is equal to 3. The subTotal parameter stores the running total throughout this process.
The difference between these two techniques is more pronounced if you consider larger factorials. If you want to calculate 40 factorial, the original factorial() function will result in extensive stack usage that will require memory enough to hold 40 deferred function calls. On the other hand, if PTC is added to the language, the factorialEx() function will grow the stack by no more than one function. Currently, however, ActionScript exhibits the same extensive stack-usage behavior for both factorial() and factorialEx().
You may be thinking that 40 or so functions on the stack are not a big deal, and we can't feed numbers to factorial() much bigger than that before we exceed the capacity of the Number type to hold the answer. I agree that this isn't a great example of the benefit of PTC, but it was useful as a simple way to explain the differences between these recursive functions. There are other examples, such as calculating Fibonacci numbers, that better show the benefits of PTC. You could write a non-tail-recursive Fibonacci function that calls itself for every addition operation. There you would run into ActionScript's recursion limit when feeding in numbers that call for more than a thousand calculations. That would mean a thousand suspended functions stored on the stack, which would contrast sharply with a tail-recursive implementation that would grow the stack by exactly one function.
Here are links to some of the materials I used in my research for this post:
In case you don't know, ECMAScript is the language standard upon which JavaScript, JScript, ActionScript and many other languages are based. The current version of ECMAScript is the third edition, but a lot of work is going on for the fourth edition. So what I'm discussing here is not currently in ActionScript, but may one day be if PTC makes it into the fourth edition specification.
]]> Today I'll start with a definition of PTC, and I'll follow up over the next few days with examples and further thoughts. You can find the ES4 proper tail calls proposal at the ecmascript.org website. I should warn you, though, that the proposals are geared more toward language implementors than users, so don't worry too much if you don't understand all the terminology they use. I'll try in this blog to translate what some of these proposals mean for ActionScript developers.Speaking of writing geared toward computer scientists, the best definition of PTC I've come across is from a journal article by William Clinger at Northeastern University titled "Proper Tail Recursion and Space Efficiency". In that paper, he talks about the essence of PTC, which I'll paraphrase in terms of ActionScript below. I have to admit that much of the article is over my head, but he writes clearly so I learned a lot from reading the sections that I could wrap my brain around. He has the article posted on his website if you're interested in further reading (http://www.ccs.neu.edu/home/will/papers.html).
According to Professor Clinger, the essence of PTC is that it provides a new way to return from a function. Namely, instead of returning a value, you can call any other function as the last thing you do. Such a function call is said to be in tail position, or to make things easier you can just refer to the call as a "tail call". This may not seem like a big deal, but it does add a new twist to the life cycle of a function.
Consider a typical ActionScript function:
function foo () {
trace("hello");
}
The foo() function will exist in memory from the time that you call it to the time that it returns from that call. The runtime (I'm going to use the word "runtime" instead of "Flash Player" or "Virtual Machine") will store the function in a special area of memory called the stack. As the name implies, a stack is organized as a last-in first-out stack, like a deck of playing cards that grows and shrinks as you add, use, and discard cards from the top of the deck. Notice in our example that we call another function, trace(), from the body of foo(). This means that foo() remains in memory while the trace() function runs. In terms of the stack, the runtime stores trace() on top of foo(). This is not a big issue in our little example, but what if it turns out that trace() calls another function, and that function calls another function, and so on. Pretty soon your stack starts getting pretty big. In fact, sometimes your stack can get too large and you get a stack overflow error.
PTC changes this behavior if the function call is in tail position. Instead of keeping foo() in the stack and placing trace() on top of it, foo() is discarded and trace() takes its place. This seems like a sensible thing to do because foo() doesn't do anything after the call to trace(), so why keep it around in memory? (Some argue that keeping it around is really helpful for debugging, but we'll talk about that another day.) And if there's a tail call in trace(), that call replaces trace() in the stack and so on. Instead of an ever-growing stack, you get a stack that may not grow at all, which will make a stack overflow exception much less likely.
PTC's ability to increase stack-use efficiency leads some people to call this feature Tail Call Optimization (TCO). However, the motivation section of the ES4 proposal for PTC states:
"Proper tail calls are not an optimization, but an aspect of the semantics of the space usage of the language."
I hope that Professor Clinger's insight into the essence of PTC helps you see this as more than just a mere optimization. If you don't, it may be because I did a poor job of paraphrasing him, so I would encourage you to read his article. Over the next few days I'll post new entries that delve more deeply into PTC. Specifically, I'll devote separate posts to recursion and how PTC is useful for programming with finite state machines.
]]>