March 2012


This one has been bugging me, and a few other people who were trying to figure out ultimately what version of SQLite is embedded in AIR. Running a SQLStatement of: ‘SELECT sqlite_source_id()’ gives us this result: onSQLresult result key sqlite_source_id() value 2010-12-07 20:14:09 a586a4deeb25330037a49df295b36aaf624d0f45.

As per SQLite.org this method returns the code characteristic for which your embedded version has been built against. Using the canonical timeline viewer, going back a few pages now of (200 entries) we find this one:

http://www.sqlite.org/cgi/src/timeline?n=200&a=2010-12-07+07%3A57%3A50
And low-and-behold down near the bottom: 2010-12-07 20:14 [a586a4deeb] Version 3.7.4 (user: drh, tags: trunk, release, version-3.7.4)

 

So it turns out, that the modified version of AIR 3.1 SQLite is based on 3.7.4 – and the real question of foreign key support is at least there – I was able to test against it using a simple CREATE TABLE, but according to the documentation- this is parsed but not enforced. Lets hope that is now wrong too – since even Adobe Employee’s couldn’t come up with this one.

Not sure how well some of us actually read this, but there is 1 section in particular that I find to be fairly interesting, and another is well, lets just say hopefully they learned since AS3 quite frankly is used in mission critical software.

Type inference: Type declarations will only be necessary in certain strategic places. Everywhere else the compiler will automatically infer suitable type declarations and treat the whole program as statically typed, even though the programmer does not have to state any types. Thus the convenience of untyped programming can be approximated quite well, while providing the performance advantages of typed programming.

So two comments on this one, one trivial the other not so much:

  1. Trivial – A lot of code-hinting programs will probably need some rework on giving the correct intelli-sense, since usually with RegEx it would be fairly straight forward (look for the next whole word after the colon where it’s declared). If I understand this correctly, basically what Adobe is hinting at is that the type declaration is only needed at the original source of the declaration? For code editors, this now means going back up the symbolic link chain to find where the parameter / class variable was originally created – this is really no small feat, and I would imagine would cause some parsing concerns.
  2. Opinion – Since when amongst any serious fundamental programmer is untyped “convenient”? Every major development platform that I know of, ALL uses strongly typed. Java, the entire C family, heck even databases do this with affinity. Seriously, it’s not convenient except anywhere more than one class is used. Typed languages have equal weight in performance (no prototypical look up), but also on the human – after all we are the ones who write this stuff, and well documented, well written code is hinged upon knowing exactly what type / interface you are dealing with at the moment.

 

Compatibility: The next version of ActionScript will be an evolution of ActionScript 3, but in some instances may not be completely compatible with ActionScript 3. We expect that any migration from ActionScript 3 will be significantly less burdensome than the move from ActionScript 2 to ActionScript 3. Regardless, we are exploring options for tooling that would either ease or automate this transition.

Adobe, please for the love of code, please don’t make us go through that again.

 

And lastly, a note on the Flex roadmap which obviously is of keen interest to me.

RSLs for Apache-released versions of Flex:
Now that Flex is a community-driven project, it is no longer appropriate nor practical for Adobe to sign the resulting Apache Flex RSLs. This means that when using an Apache Flex release, framework RSLs will not be cached globally by Flash Player, but rather per domain in the web browser.

Per domain in the browser?! Are you freaking serious? What’s the point of relying on a framework that is essentially stable and publicly available, only to have every single domain and sub-domain have to deal with loading their own copy? Wow I hope Apache is able to sign this sort of thing, and has the capacity on its servers to handle the request load.

Lastly, Flash nor Flex is dead as many in our industry fret – HTML5 is just another shiny ball that so many chase after looking for the proverbial development “fountain of youth.” Like outsourcing, it won’t be all that it’s cracked up to be and live up to it’s over-hyped promises, but instead will have it’s place in the world under certain circumstances.