Archive for the ‘ActionScript3.0’ Category

Flash Player 11 Incubator Program (Flash Player 11 孵化器计划)

Did you see the news yesterday? Flash Player 11 which includes the Molehill 3D apis, is now available to the general public as part of Adobe’s new incubator program. Get Flash Player 11 here now!.

你是否看了昨天的新闻(抱歉,我才看到,所以昨天应该就是2011.2.27)?包含Molehill 3D  api的Flash Player 11现在可以作为Adobe 新的孵化器计划的公开部分下载。Get Flash Player 11 here now!.

Then experience it within the links below:下面是一些它的表现例子

3D Racer

3D MAX Racer Game

Zombie Tycoon

Zombie Tycoon Game.

Shallow Water Demo

Away3D Shallow Water Demo

Quake 3 demo

Quake 3 demo

What is the incubator program? Here are some FAQ’s from Adobe.  //什么是孵化计划?这里是来自 Adobe的关于此孵化器计划的答疑。

FAQ: Adobe® AIR® and Flash® Player Incubator // 常见问题:关于Adobe® AIR® 和 Flash® Player 孵化器

1. What is the Adobe AIR and Flash Player Incubator? //什么是关于Adobe® AIR® 和 Flash® Player 孵化器?
The Adobe AIR and Flash Player Incubator is a place for our runtimes product teams to share new features that are either under development or under consideration for inclusion in future versions of the runtimes. Unlike our beta releases, capabilities that you see in the Incubator builds may or may not be supported in future releases of the runtimes.

关于Adobe® AIR® 和 Flash® Player 孵化器 是一个我们运行环境团队用于展示未来有可能会考虑添加的功能的地方,这不同于测试版本,因为现在我们添加的功能,在未来的运行环境中未必会加入

2. Who is this Incubator program for?  //孵化器计划针对谁?
This program is especially suitable for more adventurous developers who are willing to experiment with software features in early development stages and may or may not be included in future product releases.

这一方案是专为那些具有冒险精神的开发者,这些开发者将这些功能用于早期开发阶段的实验,可能不会在未来的产品版本中包含。

 

3. Why does Adobe have an Incubator program? //为什么Adobe要有这样一个计划
Adobe’s product development philosophy is to engage in an open exchange and involve our community of passionate developers in early stages of the development cycle. Your feedback is critical to our on-going innovation efforts for the Flash Platform.

Adobe的产品开发理念需要在开发周期的早期阶段进行公开交流,我们社区热情的开发人员,您的反馈意见对于我们正在进行的Flash平台创新有很大帮助和影响。

4. What’s the difference between the Incubator program and the beta program? //孵化计划与测试计划有什么不同
While the goals of both programs are similar — get early feedback from the developer community, the key differences include:

大的方面来说它们类似-都需要开发者的反馈意见,关键的不同点在于:

– The Incubator program allows us to get a community of developers involved in a much earlier development stage than what we do in the beta program.

-孵化计划让我们在早期的开发阶段就与我们社区开发者进行交流,而不是在测试阶段。
– The Incubator program will be focused on a collection of new features that may or may not make into any future releases, where as the beta program allows developers to experience and evaluate an upcoming release that has reached the feature-complete stage.

-孵化计划的重点放在一些新功能是否适合加入到将来的正式版本,而测试计划仅仅允许开发者体验新功能。

5. What should I expect from the Incubator program? //我应该对孵化计划有什么期待
We plan to release new Flash Player or AIR Incubator builds on a regular basis. To get updates on new builds and features, please subscribe to the RSS feed on Adobe runtimes release blog. These are early builds of AIR or Flash Player and may not be as stable as a final release. However, the current released features should still work as expected. Please file bugs for new features highlighted in the Incubator and new bugs for current released features. The availability of AIR and Flash Player and supported OS and platforms may vary on the downloads page between updates to this program.

我们计划定期推出新的Flash Player或AIR孵化器。要获取新版本和功能,请订阅及更新在Adobe的运行时版本博客的RSS。这是早期版本的AIR或Flash Player,不会想最终版本那么稳定。然而,目前发布的功能仍然正常工作。请在提交的时候标明孵化器的BUG,以及当前发布的功能的新功能的bug。AIR和Flash Player的可用性和支持的操作系统都会在下载页面做更新。

6. Why should I participate in the Incubator program?//为什么我要参与孵化计划
The Incubator program provides you the opportunity to get an early look at what our engineers are developing for two of the most ubiquitous runtime technologies in the world. By being an active participant in the program, you’ll be able to influence the future of the leading runtime technologies with the Adobe engineering team.

孵化器计划提供您有机会获得我们最早期的技术资料。通过在计划中的积极参与,您将能够影响和改变Adobe的工程团队关于runtime技术的未来。

7. Who will read my comments and answer my questions?//有人读我的意见和回答我的问题吗?
Your feedback is very important to us. Your comments and questions will be read and answered by Adobe engineers who are responsible for these features.

你的反馈对于我们是非常重要的。你的意见和问题,将会被我们负责未来发展的工程师阅读和回复。

8. What will happen to these features?//未来将会发生什么?
These features are under development or under consideration for future releases. Depending on the feedback we get from the community, some of these features will be incorporated into future releases of the runtimes.

这些功能正在开发或正在考虑放到将来的版本中。根据我们从社会得到的反馈,其中的一些功能将被纳入未来版本的运行时。

9. I have ideas for new features, who do I talk to? //我有一个好点子,我跟谁说?
We welcome new ideas from the community. Please submit your ideas to us athttp://bugs.adobe.com/flashplayer/

我们欢迎新来自社区的新点子。请发布你的点子到我们的http://bugs.adobe.com/flashplayer/

Advertisements

FlexUnit 你的第一个单元测试

呵呵,天地会有人先翻译完了。大家直接看那里就好http://bbs.9ria.com/thread-67955-1-1.html

A couple of months ago, I started experimenting with FlexUnit in FlexBuilder 3. I found myself a bit frustrated by some of the undocumented details of how to use it, so I thought I’d write an absolute beginner’s guide to FlexUnit for those who have been considering getting into Test Driven Development, but might not have the time to puzzle out features whose descriptions are a bit vague.

Getting Started

The first thing you need to do is download FlexUnit. Flash Builder 4 users have some form of FlexUnit integrated into the development environment. I recommend that you download the turnkey anyway, since my understanding is that you may not have access to the undocumented Classes that give you a nice UI for your unit tests if you use that.

Once you have the turnkey zip file downloaded, import it into your workspace–it is a Flex Project zip.

Setting up your Application

At this point, you have a choice. You can use the default FlexUnit4Turnkey as your base Application, or you can create your own. Since the three Classes that file instantiates (TestRunnerBase, FlexUnitCore, and UIListener) aren’t documented in the FlexUnit API, there’s probably limited educational value in setting this up yourself, since you have no choice but to do it exactly the way their example does it.

If you set up your own, be sure to add a function placeholder to actually run your unit tests, and remember to call it in creationComplete of your Application tag, or you’ll be scratching your head and wondering why your test didn’t run.

Writing your Object to Test

One of my biggest frustrations with the examples I could find was that they usually showed passing tests. At the heart of Test Driven Development is the idea that you first write a test, then write just enough code to pass the test, and continue writing tests and filling in functionality until your Class does everything you need it to.

In practice, I found that this is flat impossible. You need to have a certain minimum amount of code, of course, before your test will even compile, much less run, because the test will be referencing the object you want to test. So if that object doesn’t exist, you’ll get a compile error.

So the first thing I want to talk about is writing a simple Object that will compile, but will fail most tests that try to set its single property.

package com.magnoliamultimedia.testObjects
{
public class ObjectWithProperties
{
public function get someProperty():String {
return null;
}
public function set someProperty(value:String):void {

}
public function ObjectWithProperties()
{
}

}
}
Note that here, all we have is a getter and a setter. We could have written this object to have a single public variable, but then it would be pretty much guaranteed to pass any tests to see if it had set the variable correctly. I think this is part of the reason most developers don’t test simple variable assignments…not only is it probably a waste of time, but it also requires you to use a getter and setter pair to make it fail first before it passes. Still, this works well as a simple example showing how to go from a test that fails to one that passes.

Writing a Failing Test

Now we need to figure out how to write our unit test. The first thing we need to do is just create an ordinary Class. The magic in FlexUnit is done through metaprogramming, where you add simple custom etadata tags ([Bindable] and [Style] are metadata tags) to your code, and other code that encounters it can find the methods inside your Class and run them.

The most important metadata tag in FlexUnit is [Test], but if you’re going to put more than one test method in your test Class, you probably want to look carefully at some of the other ones–specifically [Before], [After], [BeforeClass], and [AfterClass]. These tags let you specify boilerplate code to run around your tests. It’s important to note that the difference betweeen the [Before] and [After] set and the [BeforeClass] and [AfterClass] set is that the first set will run before and after each and every test method, wheraes the other two will only run before the first method and after the last method in the Class.

Now that’s out of the way, let’s look at the Assert Class, which is a class with a bunch of static methods you can call from within your tests. These methods are only vaguely documented, but it doesn’t take as much trial and error as you’d think to learn how to use them. For instance, assertEquals() takes a …rest argument, which means you can essentially pass it as many arguments as you want and it’s happy. However, its documentation informatively states that it “Asserts that two provided values are equal.”

By carefully examining the provided examples, I was able to guess that, at the very least, if you give it a first argument that’s a String, and then two other arguments, then it will treat the first argument as a message and will check the other two arguments for equality. If you only give it two arguments, it will check them for equality. If you give it five arguments…well, just don’t, is all I can say.

So, armed with the knowledge of what [Before] will do and with the knowledge that any method I mark as [Test] will be run as a Test, I can now write a lovely unit test that is guaranteed to fail:

package com.magnoliamultimedia.tests
{
import com.magnoliamultimedia.testObjects.ObjectWithProperties;

import org.flexunit.Assert;

public class SimpleObjectTest
{
protected var myObject:ObjectWithProperties;
[Before]
public function setUp():void {
myObject = new ObjectWithProperties;
}
[Test]
public function setSomeProperty():void {
myObject.someProperty = ‘Hello world!’;
Assert.assertEquals(‘myObject.someProperty should be equal to “Hello world!”‘, ‘Hello world!’, myObject.someProperty);
}

}
}
Hooking it Up

At this point, I should go to my placeholder method that runs on creationComplete() and add core.run(SimpleObjectTest), so my test could run.

Interpreting the Results

If you run the Turnkey project out of the box, you will notice right off you don’t get a lot of information on what happened.

In part, this is because the default filter is on unit tests that failed, and none of them failed. But if you open up the tree, you will see that you don’t get very much information besides what tests ran.

Now, let’s look at my failing unit test.

Isn’t that much more colorful? Even more inportantly, I can see the message I used as the first parameter in assertEquals, which gives me some idea of what I was thinking should happen when I wrote the test. Above that, you can see that it took my second parameter and used it as the expected value and the third parameter as the actual value. My instinct is to want to list the value I’m testing second and the expected value last, but this would cause the expected and actual values to be reversed–which would just be confusing.

Making it pass

All we need to do in this instance is to actually fill in our getter and setter with actual values, so the Class looks like this

package com.magnoliamultimedia.testObjects
{
public class ObjectWithProperties
{
protected var _someProperty:String;

public function get someProperty():String {
return _someProperty;
}
public function set someProperty(value:String):void {
_someProperty = value;
}
public function ObjectWithProperties()
{
}

}
}
The test will now pass without any modification.

Note that I can add this test after the passing test:

[Test]
public function dontSetSomeProperty():void {
assertNull(myObject.someProperty);
}
It will also pass, because the [Before] code will initialize myObject in between tests. This is something that caught me out a few times in my first experiments with TDD, so I figured a reminder can’t hurt.

Next Steps

Walk through the Circle Test Example.

Group several tests into a TestSuite. (Note: you should definitely click on the RunWith link on that page.)

Learn to write Asychronous Tests.

Test with Theories and Assumptions.

Read more from Amy Blankenship.

Adobe为Flash Builder发布ActionScript代码覆盖插件

作者 Dionysios G. Synodinos 译者 霍泰稳

Adobe近期为Flash Builder提供了一个ActionScript代码覆盖插件,意在帮助开发者在应用运行时准确理解哪些代码被执行了。另外,该插件还提供了新的Eclipse视图,帮助开发者启动代码覆盖工具。

利用代码覆盖工具,开发者可以查看哪些区域的代码在应用执行时没有被用到,从而可以据此确定是否进行额外的测试。

该工具提供了详细的代码行覆盖和方法覆盖报告,并高亮显示没有链接到应用的类。开发者可以在基于Adobe Flash Player和Adobe AIR平台,应用Flex SDK 3.x或者Flex SDK 4.x,使用ActionScript 3开发的应用中运用Flash Builder中的ActionScript代码覆盖插件。

运行测试的先决条件包括:

  • Flash Player的调试(Debug)版本;
  • SWF文件必须已经在调试模式下被编译过;
  • 预装载的SWF必须是本地信任的。

在ActionScript代码覆盖插件发布之前,需要检查ActionScript代码覆盖的开发者,只能依赖Flexcover这个适用于Flex、AIR和AS3的开源代码覆盖工具。

至于Adobe为什么要提供代码覆盖工具,Allurent的Joe Berkovitz在2008年曾就Flexcover发布实验版本接受InfoQ采访时提到过:

我不能对Adobe进行的任何事情加以评论,但我知道他们对代码覆盖率很感兴趣,Flex技术的团队成员也正在积极思考如何去支持它。他们对Flexcover的进展也大有帮助。我很感谢他们!

 

TIOBE 2009 二月语言排行榜 (ActionScript 第十八)


Position
Feb 2009

Position
Feb 2008

Delta in Position

Programming Language

Ratings
Feb 2009

Delta
Feb 2008

Status

1

1

Java

19.401%

-2.08%

  A

2

2

C

15.837%

+0.98%

  A

3

5

C++

9.633%

+0.36%

  A

4

3

(Visual) Basic

8.843%

-2.76%

  A

5

4

PHP

8.779%

-1.11%

  A

6

8

C#

5.062%

+0.55%

  A

7

7

Python

4.567%

-0.20%

  A

8

6

Perl

4.117%

-2.09%

  A

9

9

Delphi

3.624%

+0.83%

  A

10

10

JavaScript

3.540%

+1.21%

  A

11

11

Ruby

3.278%

+1.42%

  A

12

12

D

1.259%

+0.07%

  A

13

13

PL/SQL

0.988%

+0.01%

  A

14

14

SAS

0.835%

-0.11%

  A

15

22

Logo

0.813%

+0.50%

  A–

16

17

Pascal

0.689%

+0.24%

  B

17

29

ABAP

0.574%

+0.42%

  B

18

21

ActionScript

0.539%

+0.22%

  B

19

26

RPG (AS/400)

0.505%

+0.33%

  B

20

18

Lua

0.487%

+0.10%

  B


Position

Programming Language

Ratings

21

FoxPro/xBase

0.484%

22

COBOL

0.470%

23

Lisp/Scheme

0.433%

24

MATLAB

0.417%

25

Ada

0.349%

26

Fortran

0.305%

27

Transact-SQL

0.290%

28

PowerShell

0.261%

29

LabVIEW

0.228%

30

Prolog

0.205%

31

Erlang

0.192%

32

Objective-C

0.181%

33

Scratch

0.166%

34

Alice

0.163%

35

Haskell

0.161%

36

NXT-G

0.157%

37

ML

0.155%

38

Awk

0.144%

39

Euphoria

0.134%

40

Groovy

0.129%

41

Caml/F#

0.127%

42

Progress

0.119%

43

Focus

0.119%

44

Bourne shell

0.118%

45

Smalltalk

0.116%

46

Q

0.114%

47

CL (OS/400)

0.113%

48

Scala

0.113%

49

Forth

0.107%

50

Tcl/Tk

0.106%

Prana Framework力推ActionScript 3应用开发

作者 Moxie Zhang  译者 张龙

Prana是一个面向Adobe Flex及ActionScript 3的控制反转(Inversion of Control,即IoC)应用框架。InfoQ最近采访了Prana Framework的创建者Christophe Herreman和Damir Murat以深入了解该框架的使用。

InfoQ:您能否向InfoQ的读者说明一下当初为何在其他控制反转应用框架已经存在的前提下还要开发Prana呢?

Herreman:Prana诞生于我们开始重写之前用ActionScript 2和Flash开发的一个在线学习平台之际。我们使用的一个库是来自于as2lib的IoC容器,由于之前IoC对我们的工作提供了巨大的帮助,因此我们想在自己的这个新平台上也添加同样的功能。那时还没有ActionScript 3的IoC容器,所以我打算自己开发一个。

我以一个自己的实现(基于Spring XML方言)开始,但很快我就决定尽可能地以Spring提供的代码作为基础。这样做更容易实现某些特性,因为可以参考Spring的源码;熟悉 Spring的开发者使用Prana时会很容易上手,当然我也借此机会更深入地学习Spring的内核。

InfoQ:您认为Prana framework最突出的特点是什么?

Herreman:它是一个通用、可扩展、功能强大的IoC容器。如果你了解Spring IoC容器,那么你就会清楚Prana能做些什么。

它有一个很棒的特性:你可以向其XML解析器中增加自定义的预处理器。预处理器用来转换已加载但尚未解析的XML。接下来,你可以增加新的元素和属性以方便地描述自定义对象,同时还可以让自定义的预处理器将元素转化为Prana解析器可以理解的形式。

除了IoC容器,Prana还有一个构建于describeType()之上的Reflection API。这样你就可以在运行时获得对象的信息,比如对象包含的属性和方法以及实现的接口等等。接下来,我们还为领域对象创建了一些基础类(这是从Eric Evans的Domain-Driven Design一书中得到的灵感)。这些基础类具有比较和克隆对象等逻辑。Prana还包含几个有用的帮助类。

Murat:Prana还提供了一些工具,这些工具可用来快速建立基于Prana的项目。其中一个主要特性就是动态更新Flex编译器的配置信息以包含编译好的swf中的类,而这些类是无法通过代码访问的。这在IoC系统中很常见,因为IoC鼓励面向接口(而不是类)编程。我们的工具与Eclipse/Flex Builder紧密集成,同时他们可以检测到Prana的配置信息何时发生了变化,如果需要的话,他们就会解析Prana的配置并相应地更新flex编译器设置。当程序员必须显式声明无法通过代码访问的类以将其包含在最终编译好的swf中时,这种方式就无需再使用典型的flex“模式”了。我们的工具会自动完成这些事情。

还有其他一些特性,如预定义的项目布局、定义好的Ant target,对subversion的支持等等。所有这些特性都是可配置的,并可通过几个步骤轻松搞定。开发者可以查看prana-tools项目(从svn或是分发包中都可以得到)以了解感兴趣的信息。

InfoQ: Prana集成了Cairngorm和PureMVC。您能否说明一下Prana为什么要与这两个框架集成,并且是如何实现集成的?

Herreman:我们为Cairngorm和PureMVC提供了一套扩展。因为我们使用了IoC,所以我们还想将该原理应用到我们正在使用的框架上,同时我们想用依赖注入(Dependency Injection,即DI)对应用的不同部分进行包装。

我们为Cairngorm提供了一个可配置在IoC容器中的服务定位器。你可以在外部定义远程对象、channelsets、consumers等,并可以改变他们而无需重新编译应用。通过这种方式,你也无需编译services-config.xml文件并可以轻松地将其部署到不同的地方。它还使测试变得更简单。典型的例子就是当你从开发机器迁移到测试或是产品服务器上时,你得改变端点(endpoints)。Prana使这一切变得简单,你无需重新构建应用。

我们提供的frontcontroller是Cairngorm frontcontroller的一个子类,它接收定制的命令工厂。通过这种方式,你可以控制命令创建的方式,一旦命令创建好后,你就可以将额外的属性注入到命令中。除此以外,我们还支持链式的事件/命令,这样你就无需显式地从另一个命令中调用命令了。

Murat:与PureMVC的集成最初只是一种实验性的尝试,用来将IoC带到PureMVC应用中。后来发现这是可行的,于是我们就将这项工作公开了。

对于PureMVC用户来说,主要的好处是当遇到依赖时可以使用依赖注入。同时这也是最大的缺点,因为DI的使用不可避免地会改变一些原始的 PureMVC使用习惯,而这些习惯是基于服务定位器模式的。然而我们相信DI对任何应用都是很有帮助的,PureMVC也不例外。为了减轻移植到DI的代价,我们尽可能简化Prana的PureMVC集成。例如,PureMVC开发者可以选择一个DI的应用范围。Prana只能用来管理非PureMVC 对象,或者说它只能用来管理部分PureMVC类,当然它可以管理应用中的PureMVC对象和非PureMVC对象。

InfoQ:能不能推荐一下使用Prana的最佳方式(或者是应用类型)?

Herreman:如果你需要在应用中保持一定程度的灵活性以便其可以运行在不同的上下文中,或者是你拥有大量的配置,想要集中管理他们,那么我极力推荐使用Prana。因为它基于Spring,很多开发者已经熟悉了其概念和XML方言。

就我们的情况来说,我们已经创建了一个在线学习平台,用户可以定制其自己的需求。因为我们自己管理该平台,所以需要有一种机制以允许所有这些定制。如果没有IoC,我们就不得不对每个定制编译不同的软件版本,或者是我们必须编写一个基于XML或者是数据库的客户配置系统,而对其的维护绝对是一个噩梦。与此相反,我们可以让每种定制都有一个应用上下文,当应用加载时就去装载该上下文,这取决于登录的用户。更酷的是我们可以从ASP页面(需要从数据库中读取配置)中即时生成应用上下文。

InfoQ:Prana的长期计划是什么?

Herreman:最重要的事情就是IoC容器,我们期望1.0版会有一个稳定的容器。目前来看,容器本身很不错,但我们还可以改进一些东西,增加更多的Spring特性,如parent beans及自动装配等。我们还需要编写一些文档。

我们一直在与开发团队探讨将扩展(Cairngorm、PureMVC等)从主代码库中移除,然后将其作为独立的扩展库发布。这么做将有利于发布管理。

我还准备开发一个AOP(Aspect-Oriented Programming,面向方面的编程)框架,但遇到了一些麻烦,这些麻烦是由ActionScript 3的一些限制导致的。AOP背后的主要思想是基于动态代理机制创建新的对象类型,该对象会在运行时实现一些接口。问题在于这在ActionScript 3中是不可能的。我们已经在Adobe JIRA上发布了这个话题,如果有人愿意与我们分享一些见解的话我将感激不尽。该话题位于:http://bugs.adobe.com/jira/browse/ASC-3136

至于其他方面,我们还没有制订严格的路线图。当我们有新想法时就会引入一些新特性和进行一些改进,我们一直在倾听来自其他开发者的建议,同时还期待有更多的人能加入到我们的团队中。

查看英文原文:Prana Framework Helps on ActionScript 3 Application Development

ActionScript 3.0争论何时休?

作者 Moxie Zhang   译者 沙晓兰

自从独立Flash平台专家——Colin Moock七月份在O’Reilly InsideRIA发表了一篇名为“The Charges against ActionScript 3.0”文章之后,Flash/Flex社区内的争论一时间硝烟四起。

“……很多Flash用户仍然对ActionScript 3.0中引入的一些工作流方面的变化望而生畏。这些改变本身真正存在问题的很少,但当他们集合到一起的时候,就对Flash用户典型的日常工作产生不可磨灭的影响。” Moock的这句话是引发整个争论的导火索。

Moock在文章中指出了9条对ActionScript 3.0的不满:

    1. Flash CS3去掉on()/onClipEvent()以后,即使是简单的交互都很难创建。
    2. 很难习惯没有加载的.swf文件。
    3. 向上溯型 DisplayObject.parent使得父对象的clips很难控制。
    4. 没有getURL()之后,连接比较困难。
    5. 没有loadMovie(),加载.swf文件和图像都不方便。
    6. ActionScript 3.0中其他一些错误导致编程非常麻烦。
    7. 动态指向类库符号一点都不直接。
    8. 向手动创建的文件域、所有影视片段、所有按钮添加定制功能很费时间。
    9. 去掉duplicateMovieClip()之后,复制MovieClip实例变得非常困难。

Moock针对上面列出的每条都做了深刻的解释,也提出了一些建议。Atlanta Flash Community的Leif Wells表示有同感,他说:“毫不夸张地说,在我们向社区成员展示一些ActionScript 3.0的代码的时候,就遇到一些成员因此浑身冒冷汗。他们现在大都对 Flash Player 10的特性比较感兴趣,但很多人目前为止还无法掌握这些特性。”

然而,andCulture的主管Francis Lukesh从另一个角度来审视Flash的改进。他说:

有的人从Macromedia收购FutureSplash之后就开始使用Flash;有的人除了有设计动画的背景以外还有编程经验。对于这些人,我赞同Adobe的决定,赞同他们在Flash中借助AS3来提供更具结构化的ActionScript实现。我想信,这一极具决策性的手笔能够把 Flash打造成一个真正的RIA开发值得选择的平台。

说工具箱不能通过编写抽象的API来提供文章中提到的那些功能是毫无理由的。实际上,这样的工具箱能够帮助设计师、动画制作者在保留AS3完整构架的基础上提高他们的开发效率。

Exanimo的Matthew Tretter以开发者而不是设计者的身份表示不同意作者的观点:

通常,我对那些编程语言为了尽量让非程序员都能应用而所作的改变很麻木(相反,我觉得编程语言应该要尽量方便程序员的应用)。在你提出的那几点中,我觉得有些其实根本不是因为功能难用,只是跟之前不一样罢了。习惯了以前的某种用法,并不意味着这种用法就是直接的,或者说是简单轻巧的。有时候,那些习惯用法实际上反而很费力,就比如说这个on()构造。

Flex开发员Steve的意见似乎比较中庸,他说:“作为一个全职的AS3开发员,在Flex Builder这种‘奢侈‘工具的帮助下,我没怎么遇到文中提到的那些不便。但在使用Flash很多年以后,我完全理解这些忧虑。“

另一个Flash开发员John Isaacks说他已经把习惯改过来了:

我从版本4的时候开始使用Flash(编程、制作动画)。ActionScript是我学习的第一门编程语言。在ActionScript 3刚推出的时候,我感到非常恐惧,主要是因为在新建一个flash文件,以之前习惯的方式编写代码的时候,我得到的却是很多错误提示。

……现在,我比此前任何时候都理解ActionScript。我也觉得AS3在很多方面没有AS2那么直接(有些时候,我还是会发现自己不自觉地在用一些AS2中的简易方法)。

Moock这样回复这些异议:

坦率地说,我还是强烈支持使用变化不多的编程工具。我喜欢ActionScript 3.0,也觉得Flash成长为一个开发平台是件很不错的事情。Adobe终于为程序员提供一些功能强大的工具——比如Flex Builder、ActionScript 3.0 profiler、 ASDoc、ANT集成、数据服务、干净利落的debugger、命令行编译器、Flex框架、公用的bug数据库、针对UI开发的MXML等等,这令人非常振奋。可见,Adobe对Flash程序员这个群体还是提供了很多支持的,而且他们的努力也必然能够吸引更多的开发员来使用Flash。

随着技术的推进,这类“健康”的讨论也会延续下去。

查看英文原文:Is the ActionScript 3.0 Debate Over?

六月开发语言排行榜出炉 ActionScript回前20

TIOBE开发语言排行榜每月更新一次,依据的指数是基于世界范围内的资深软件工程师和第三方供应商提供,其结果作为当前业内程序开发语言的流行使用程度的有效指标。流行的搜索引擎包括Google、MSN、Yahoo!和YouTube等。
该指数可以用来检阅开发者的编程技能能否跟上趋势,或是否有必要作出战略改变,以及什么编程语言是应该及时掌握的。观察认为,该指数反应的虽并非当前最流行或应用最广的语言,但对世界范围内开发语言的走势仍具有重要参考意义。
根据最新出炉的六月份开发语言流行度调查显示,前三甲仍分别被Java,C,C++占据,三者的总份额约占到45%,显示了三大主流语言在世界范围内的统治地位。Java在Web服务器端的地位一直相当牢固,而C,C++则是套装软件,基础软件和大量硬件设备研发的主流开发语言。
值得注意的是,PHP比去年同期大幅上升了1.33%,其应用程度大大超出预期,这也与当前市场上PHP人员需求状况比较一致,反应了其在Internet应用开发上的迅速崛起。由于Flash的应用在逐渐推广,ActionScript重新杀回前20名。详情见下图:

10种语言使用情况曲线图: