Archives For Actionscript

In actionscript there is no splat operator or argument unpacking.

In the case where you want to proxy calls to vararg methods you have to use the Function#apply() method.

var array:Array = [];
var stuffToAdd:Array = [ 1, 2, 3, 4 ];

array.push.apply(array, stuffToAdd);

It would be nice to have a splat/unpack operator:

array.push(*stuffToAdd);
// Or
array.push(... stuffToAdd);

The ecma mailing list discussed this use of super.apply(this, arguments). And specifically regarding argument unpacking in AS3:

We dropped this from AS3 for lack of evidence for its need.

I think any language with (... args) to Array needs the Array to (... args) if not for anything other than completeness. Does anyone know if this is planned for ES4 at least?

Currently when using the flash.net.Socket api, there is no way to
determine that buffered data has been written to the socket. (The flush method is non-blocking and applies only to the actionscript socket buffer).

This is a follow-up to a previous post.

This issue does not arise when using the new File api (and writing to
files), since an event has been included in
flash.filesystem.FileStream: OutputProgressEvent.OUTPUT_PROGRESS

If this (or a similar) event could be added to the Socket api, it
would allow us to:

  • Send large amounts of data on a socket (without causing large memory
    usage as data buffers in memory).
  • Measure the current progress of data being sent on the socket.

We came upon this limitation from using our AS3 http client library, and trying to send large
files as part of a multipart upload. However this issue would arise
when sending any significant amounts of data on a socket. For example, an FTP or bittorrent client would be impossible.

This issue has been discussed in other places, but is probably more
pressing now with the AIR releases.

Update:

I was looking at different type systems (apparently there are 4 dimensions) in different languages and ran across this use of duck typing in C# :

For example, the C#’s foreach operator already uses duck typing. This might be surprising to some, but to support foreach in C# you don’t need to implement IEnumerable! All you have to do is:

Provide a public method GetEnumerator that takes no parameters and returns a type that has two members: a) a method MoveMext that takes no parameters and return a Boolean, and b) a property Current with a getter that returns an Object.

Do you have multiple fine-grained interfaces (like IEnumerable and IEnumerator and ISupportsAdd) or a single interface with all the methods and maybe they throw UnsupportedOperationExceptions if they don’t actually support a particular call (like in a mutable versus immutable collection)?

The closer you get to more fine grained interfaces like ISupportsAdd<T> or Closeable, defining a contract for a single method Add(T obj) or Close is that you might as well just ask the class if it has that method (if it “quacks”) instead of whether it implemented a single method interface. Better yet, just assume it and let it throw an error at runtime. Whatever the compiler doesn’t give you, some decent test coverage will.

But what strikes me as particularly great is that foreach is obviously such a powerful thing to restrict to a single interface, and so they chose “Duck Notation”, because in this case it is worth it.

This reminded me of why I like ecma 4 (and its derivatives like actionscript). You have freedom to use static and dynamic typing at will.

If you check out my take on an AS3 HTTP client library, HttpRequest class and allowing the request body to be of any type:

public class HttpRequest {

  // Request method. For example, "GET"
  protected var _method:String;

  // Request header
  protected var _header:HttpHeader;

  // Request body
  protected var _body:*;

  /**
   * Create request.
   *
   * The request body can be anything but should respond to:
   *  - readBytes(bytes:ByteArray, offset:uint, length:uint)
   *  - length
   *  - bytesAvailable
   *  - close
   *
   * @param method HTTP Method, for example 'GET'
   * @param header HTTP request header (or null)
   * @param body HTTP request body (or null)
   *
   */
  public function HttpRequest(method:String, header:HttpHeader = null, body:* = null) {
    _method = method;
    _header = header;
    _body = body;

 ...

I think this is a good choice because:

  1. The IDataInput interface (that ByteArray already implements) doesn’t have a length property and we need to know the request body size (Content-Length) before we send.
  2. The IDataInput interface wants you to implement a ton of read methods, which would make it annoying to force people to implement.
  3. ByteArray has these methods and also implements the length property already. It quacks.
  4. If we created our own interface with these methods, we can’t add this interface retroactively to ByteArray.
  5. I wrote it. Heh.

The other option is to subclass ByteArray and have that implement the new interface, but it just seems awkward (in this case) having any empty subclass solely for the point of enforcing an interface.

Another place where this principle applied for me is in HttpSocket. We need to support both Socket (for http) and TLSSocket (for https). TLSSocket has all the same (mostly) methods as Socket (but does not extend Socket; yay for composition over inheritance). Creating a proxy to delegate to different socket implementations based on the http scheme is an option but to me wasn’t worth it. And using a design pattern to overcome the lack of an appropriate and existing interface just seems to make things worse.

Closures

December 28, 2007 — 3 Comments

There is alot of debate going on between the CICE and BGGA proposals for Java closure support.

I thought I would try to experiment with the different proposals and compare to languages I am using right now. I picked something simple to try out, like summing an array of integers:

Also check out good closures, bad closures.

Actionscript 3

Assume you have a reduce function, for example:

public function reduce(array:Array, f:Function, index:int = 0):* {
  if (index == array.length - 1) return array[index];
  return f(array[index], reduce(array, f, index + 1));
}

Then the syntax is:

var array:Array = [ 1, 2, 3 ];
reduce(array, function(x1:Number, x2:Number):Number { return x1 + x2; });

Ruby

Sorry I have to.

array = [ 1, 2, 3 ];
array.inject { |sum, n| sum + n }

or with Symbol#to_proc:

array = [ 1, 2, 3 ];
array.inject(&:+)

Java (CICE)

Assume you have a “Reducer” interface (and Collections#reduce):

interface Reducer {
  T reduce(T t1, T t2);
}
List = Arrays.asList([ 1, 2, 3 ]);
Integer sum = Collections.reduce(list, Reducer(Integer x1, Integer x2) {
  return x1 + x2;
});

I think this is right, help? So you might have to declare new interfaces if the API doesn’t have them. It would probably have common ones though.

Java (BGGA)

Assume you have Collections#reduce:

List = Arrays.asList([ 1, 2, 3 ]);
Integer sum = Collections.reduce(list, { Integer x, Integer y => x+y });

The other powerful thing with the BGGA proposal is the control invocations, like:

Lock lock = new Lock();

Lock.withLock(lock) {
  doSomething();
}

// Automatically close stream when done
with(FileInputStream f : exp) {
  doSomething();
}

Like in Ruby:

mutex = Mutex.new
mutex.synchronize do
  doSomething
end

File.open("foo.txt", "w") do |file|
  doSomething
end

Since I’ve been doing Ruby lately, I know which Java proposal I prefer. The CICE doesn’t address the problem that within an anonymous inner instance return, and this and any anonymous instance methods are scoped to that anonymous instance and not the enclosing method.

I guess CICE is more about reducing the verbosity of the anonymous instance declaration and allowing mutability on public variables, and its not a real closure in the strict definition. I know people refer to anonymous inner classes as the poor man’s closure, but I don’t really think of it as a closure, I think of it as, you know, an anonymous inner class.

Flush

December 27, 2007 — 3 Comments

So I decided to try to overcome the Leopard File.upload() bug by rolling my own http client: as3httpclientlib which even supports https with the TLS (Socket) support from as3crypto (which is great). The HTTP protocol is pretty simple and I figured it would be a good way to learn the internals and look smart reading ancient RFC‘s. All you need is a Socket class and nice, flash api has one at flash.net.Socket

I got everything major working like GET, PUT and POST with multipart/form-data and reading chunked encoding and all that stuff. Not too hard since there are open source http libraries for every major language. I looked at ruby Net::HTTP (stole some regex’s) and Apache Httpclient (stole your multipart boundary).

I got to the point where I was testing uploading larger files, like in:

var client:HttpClient = new HttpClient();
var uri:URI = new URI("http://mybucket.s3.amazonaws.com/big.mp3");
var testFile:File = new File("app:/test/assets/big.mp3");
client.upload(uri, testFile);

It turns out that when you call _socket.flush() (in HttpSocket) it doesn’t actually block, which you might expect. After thinking on it, this isn’t totally shocking since the whole threading model behind actionscript, you don’t really ever block (like there is no such thing as a modal dialog in flash). The problem is without blocking or an event to notify of a flush, the socket just gets filled with the request body all at once (all 800MB’s or whatever file size).

It turns out other people ran into this as well. If you look at (FlexFTP) source, the UploadInv.as file, you will see block of code commented out and replaced by a setInterval(.. , 300). Nice. I guess that upload is capped at ~12kb/sec.

Any of the links in the comments off this blog post are useful too.

If you look at FileStream object you will see it has an outputProgressEvent so that would be useful, you know, if Socket had that too.

I don’t know how you get around this issue, other than trying to guess how fast the socket can transmit and try to stay under that. So now I’m not sure what to do, other than abandon it and come back to it when its fixed, which hopefully will be soon. Thankfully, I can go back to ruby and maybe play with some RubyCocoa or Shoes framework.

Update: Feel free to chime in at Adobe Air Forum or Feature Request/Bug Report Form

Publishing, testing, and running Actionscript projects is a pain.

“AsProject automates a variety of tasks including the creation of projects, classes, test cases, test suites, and swfmill libraries. It automates the download, installation and configuration of the debug flash player and many open source tools. AsProject also includes sophisticated build tools written in rake to automate build processes.”

Video demo or Project page


gem install asproject

Also, a friend Corey pointed out that you can debug flash using Actionscript ExternalInterface to log to Firebug console.log instead of using ASUnit’s debug console. In your actionscript:


 ExternalInterface.call("console.log", "FLASH: " + s);

And make sure to allowScriptAccess.

1
2
3
var so = new SWFObject("flash/xxx.swf", "myswf", "680", "200", "8", "#FFFFFF");
 so.addParam("allowScriptAccess", "always");
 so.write("xxx");

And you could call any javascript from it. ExternalInterface is a replacement for fscommand. I don’t remember but I don’t think ExternalInterface works in all browsers.