Sbktech

I spent a couple of weekends playing with a simple scheme-ish interpreter in Flex, you can see the results below.

Click the Scheme! button to open up a console, click on the Eval button in the console to do some simple calls into flex.

It's not really scheme, and it's pretty crude -- but it has enough (lambdas and static scoped ariables) that you can do a reasonable amount of flex prototyping, or "within-app-extensions" fairly comfortably. Always assuming that you find scheme comfortable, but that's another story...

I've used a subset of Javadot notation to call objects and methods within flex. So for instance, if you want to reposition the button, you can simply eval

(.y$ my-button 200)

which is the notation to set a property on an instance. To call a method, you provide the method followed by the object. For example, the underlying canvas in the app is referenced by the variable workspace, so to add a new child you eval

(.addChild workspace (mx.controls.ColorPicker.))

which also shows how you can make a new instance of a class (by appending a "." to the class name.)

You can also create functions that can be registered within Flex. For example, you can register a listener for click events on the button with

(.addEventListener my-button "click" (lambda (event) (mx.controls.Alert.show event)))

and now clicking the button should put up an alert.

You can also load existing scheme code by using the .loadFile method in the interpreter. And As an extra bonus, I also wrote a little inspector (in Flex, not scheme) that examines variables, properties and methods in any object. To see both these things, eval

(.loadFile evaluator "http://schemeflex.googlecode.com/svn/trunk/src/scheme/util.scm")

followed by

(inspect my-button)

and you should see (rather slowly) an inspector and you can play with the various settings in the button, click on referenced objects to open new inspectors, etc. The inspector is quite inefficiently implemented, but adequate to explore some of the hidden nooks in Flex and see what they do.

A couple of magic variables: workspace is the canvas where the evaluator runs, and evaluator is a reference to the currently running interpreter object.

Get the source code here Enjoy!