This project has moved. For the latest updates, please go here.


April 10, 2014 (release

After finding out that the Method handling in the newer versions was very unstable, I have rolled back to use the 1.0.4 version. Also added support for if-then-else, switch statements and parsing statements and statement lists.

March 12, 2014 (AntlrParser branch)

Added Antlr-based parser (branch: AntlrParser). This branch will be used moving forward. The use of Antlr makes it easier to add support for parsing new language elements. Implementing them though, is another question...

February 12, 2014 (release 1.0.3)

Improved detection of dynamic objects with a check to see if the class has any interface IDynamicMetaObjectProvider instead of checking for ExpandoObject only.

February 2, 2014 (release 1.0.2)

Ternary operator support has been added.

A new feature "ScopeCompile" has been added. This allows you to compile an expression that can contain variables that are not registered during initialization but are instead passed on an object as a parameter to the compiled function. Refer to the Documentation for details.

Dynamic objects (dynamic keyword/ExpandoObject) are now supported. The code generated uses callsite binding on operators and member accessors mimicking the way C# 4.0 compiles dynamic code.

The params keyword is now supported for methods that use this. The code uses a weighting algorithm that relies on the predefined type precedence to determine the method that best matches the parameters.

For example, if you had methods sum(params double[] values) and sum(params int[] values) and you compiled "sum(1,2,3,4,5)" it should bind to params int[] as it is the best match. However, if you had methods sum(params double[] values) and sum(params float[] values) it would bind to params float[] as it is the closest match.

May 30, 2012

The API has been slightly changed. As of changeset d28640eceb5c instead of creating an instance of the Parser class, you should create an instance of the CompiledExpression or CompiledExpression<T> class.

The difference between the generic version and the non-generic version is that the non-generic version incurs the additional overhead of boxing the result into type Object. It helps that if you actually know what type you are expecting beforehand, you should have a slight performance increase. This is untested, but I just wanted to have a cleaner API. Otherwise most everything else on the API side remains the same.

Last edited Apr 10, 2014 at 4:32 AM by RupertAvery, version 9


No comments yet.