Walking in ShockScript plan

[hydroperx]

ShockScript ≈ ActionScript 3

• Relation: MXML
• Relation: AS3

Markup: Discards MXML in favour of XML expressions for implementation-provided behavior (and they can still be used for XML and XMLList based on context type).

E4X proxying: E4X syntax may be proxied (shock_proxy).

Wildcard: o.(test) and with (o) {} have undergone change: they use a * binding. Simplifies lookup a lot (e.g. xnode.(*.@x.startsWith("a"))).

decimal, BigInt: IEEE 754 quadruple precision floating point (binary128) and arbitrary range integer, respectively.

Complexity: Inherits some of TypeScript structural type baggage. Its iterators may remind of Java and Rust. Keeps RTTI. Lots of type inference.

Compatibility: Incompatible with AS3 in many ways, but tasties the same way.

Source paths: The plan is to just glob recursively like .NET languages/compc.

Lambda brevity: Arrow functions are way complex (due to destructuring patterns), so my take was ES4 function() exp, but in turn XML expressions support a shorthand event&={statementList} attribute equivalent to event={function(event){statementList}} (e.g. click&={trace("clicked!")}.

ES4 lookalike: switch type, unions (void, decimal, Boolean), arrays [T], function types function(T1, T2=, ...[T3]):E, lambda brevity, and more.

Event name/type inference: at-eventType discarded because static constants are not in convention anymore. Here we got like TypeScript, but a little better.

Clonage: o.clone(); default implementation will suffice for optional constructors.

Overriding: Nicer. You can add more optional and rest parameters on a subclass.

Package recursive import: When importing recursively with com.business.calculator.** just make sure your lookup won't find two conflicting names.

Alias imports: import c = com.business.calculator.**; c::x

Map: Feels natural like flash.utils.Dictionary, but supports E4X like lookup and methods like length().

Feel free to opinate!

[hydroperx]

I've changed the Embed() expression so that by default it inserts the file at the application's installation directory, returning an app:// URL.

The app:// URL should resolve more instantly when running in the device's file system. When targetting HTML5, I guess we can internally use Origin-Private File System and preload files into there.