What's new in V8.NET 1.4.0.1
Dec 19, 2013
- Breaking change: While working on DreamSpace it occurred to me that running actions in scopes is just a pain in the @$$. ;) I did a speed check and found this: > Using action callbacks ...
- > 20000000 loops @ 32679ms total = 0.00163395 ms each pass.
- > Using native stack scopes ...
- > 20000000 loops @ 21378ms total = 0.0010689 ms each pass.
- It's clear there's really not much benefit because I think the majority of V8.NET users are creating non-linear calls to the engine, and thus it's faster to stick with the native V8 side scopes on a per P/Invoke call basis (which I sort of suspected - though the goal was to mimic V8 at the time). Besides, I think it will also help cut down on a lot of bugs if in case someone forgets to use a scope.
- "{ObjectTemplate}.RegisterInvokeHandler()" should take a JSFunction as a callback, and not the native callback signature. This has been corrected
- Implemented IDisposable for V8Engine
- Bug fixes
New in V8.NET 1.3.14.39 Beta (Sep 11, 2013)
- Fixed a bug in the garbage collection process where managed functions from function templates might disappear, causing the native script call to fail.
- Many bugs fixed in the new binding system, which is much more efficient! Security has also been enhanced, so implicit binding of types, by default, will not show any properties unless you explicitly register the type using "{V8Engine}.RegisterType()".
- Breaking change: Generic invocation will change from the form 'SomeMethod$#([types...])(params...)' (where '#' is the number of expected types) to 'SomeMethod$#([types...], params...)', which is more efficient, and allows faster binding and invoking. Same number of characters actually, and the first argument to a generic method must be an array of types (or values to get types from).
- Added "{ObjectTemplate}.RegisterInvokeHandler()" to allow invoking non-function objects, created from templates, like function objects.
- Added "{TypeBinder}.ChangeMemberSecurity()" to modify security on types you don't have control over. You can get a type binder using "{V8Engine}.GetTypeBinder()".
New in V8.NET 1.3.0.2 Beta (Aug 26, 2013)
- Very easy to deal with accessing nested properties/objects on the managed side (DLR).
- Added methods to make it easier to bind existing .NET object instances and types to the V8 JS environment.
- Created a new function '{V8Engine}.LoadScript(string scriptFile)' to make it more convenient to load JS files.
- Breaking change 1: Some handle property names were refactored, and some added so that handles can have full access to the native objects without having to create V8NativeObject instances (too much extra overhead I wanted to avoid). In fact, V8NativeObject now wraps a Handle and redirects dynamic requests to it, and both Handle and InternalHandle implement the same methods for working on the native JavaScript objects (so that's all you need to access/update in-script objects!). This was done to allow dynamic property access on the handles without having to create another object to do it. This change slightly affects the members and functionality of the V8NativeObject - but mostly behind the scenes. This allows accessing objects easily using a chain of property names, such as '((dynamic){someHandle}).a.b.c.d...' or '{object}.AsDynamic.a.b.c.d...'.
- Breaking change 2: V8NativeObject will now have a generic object (V8NativeObject) version to allow injecting your own objects into it instead of deriving from it (deriving is recommended however). I wanted to get rid of the internal "_ObjectInfo' objects that were holding member data that really should be in the object itself. This will mainly affect only those who need to implement the interface (IV8NativeObject) instead of inheriting from V8NativeObject. Under the new system, when the "Initialize()" virtual method is called, you just cache a pointer to the 'V8NativeObject' instance wrapping your object and use that instead.
- Refactoring the files to better support the coming Mono port. 8) Special thanks to rryk for getting the ball rolling. To this end, I'll also be converting the source repository to Git! :) You're welcome.
- Breaking change: (already!? yes. ;) ) After some retrospecting, I think it's better to update an ObjectTemplate to spit out objects for a given types more quickly than having the type binder set accessors for each new bound instance. This is a small change, and simply requires to call "RegisterType()" on the engine instance instead.
- Added "Prototype" to InternalHandle and ObjectHandle.
- Added 'SetProperty()' and 'SetAccessor()' to 'ObjectTemplate' to call the corresponding "Set()" and "SetAccessor()" functions on the native ObjectTemplate instance. This allows setting up your own properties on the template without needing to implement a custom 'V8ManagedObject' instance.
- Static types are now supported when binding CLR objects to JavaScript.
- Spaces removed from paths and file names to better support cross-platform compatibility with IDEs such as MonoDevelop. The test project was also removed (was never used anyhow - testing is done in script form via V8).
- More Bug fixes.
New in V8.NET 1.2.54.7 Beta (Aug 21, 2013)
- Completed Updates This Release:
- Very easy to deal with accessing nested properties/objects.
- Added methods to make it easier to bind existing .NET object instances and types to the V8 JS environment.
- Created a new function '{V8Engine}.LoadScript(string scriptFile)' to make it more convenient to load JS files.
- Breaking change 1: Some handle property names were refactored, and some added so that handles can have full access to the native objects without having to create V8NativeObject instances (too much extra overhead I wanted to avoid). In fact, V8NativeObject now wraps a Handle and redirects dynamic requests to it, and both Handle and InternalHandle implement the same methods for working on the native JavaScript objects (so that's all you need to access/update in-script objects!). This was done to allow dynamic property access on the handles without having to create another object to do it. This change slightly affects the members and functionality of the V8NativeObject - but mostly behind the scenes. This allows accessing objects easily using a chain of property names, such as '((dynamic){someHandle}).a.b.c.d...' or '{object}.AsDynamic.a.b.c.d...'.
- Breaking change 2: V8NativeObject will now have a generic object (V8NativeObject) version to allow injecting your own objects into it instead of deriving from it (deriving is recommended however). I wanted to get rid of the internal "_ObjectInfo' objects that were holding member data that really should be in the object itself. This will mainly affect only those who need to implement the interface (IV8NativeObject) instead of inheriting from V8NativeObject. Under the new system, when the "Initialize()" virtual method is called, you just cache a pointer to the 'V8NativeObject' instance wrapping your object and use that instead.
- Various Bug fixes.
- Some quick start notes: Use "TypeBinder.RegisterType()" to register your types in V8.NET (this has nothing to do with JavaScript - this only creates a cached binder for the type). This is not required, but does give you more control.
- There's two new "SetProperty()" methods: one for binding an object instance, and another to store a type as a function property (to use with "new").
- There are two attributes to use on your custom objects: 'ScriptObject' and 'ScriptMember'.
New in V8.NET 1.2.28.23 Beta (Jul 16, 2013)
- This release has the interface DLLs renamed to prevent Visual Studio from pulling them into the parent folder (you may get a warning in the output window, but you can ignore it).
New in V8.NET 1.2.23.5 Beta (Jun 26, 2013)
- Fixed some minor bugs.
- Added the ability to reuse existing V8NativeObject types. Simply set the "Handle" property of the objects to a new native object handle (just write to it directly).
- Example: "myV8NativeObject.Handle = {V8Engine}.GlobalObject.Handle;"
- Supports .NET 4.0! (forgot to compile against .NET 4.0 instead of 4.5, which is now fixed)