Develop Reference

Fastest Way to Wrap C++ Object in Native NodeJS Addon

As the title says, I am looking for the fastest way to wrap a native C++ object into a v8::Object. A sample of the code I currently have looks like:
Nan::Persistent<v8::Function> Vector3::constructor;
void Vector3::Initialise() // Static, Called once.
{
v8::Local<v8::FunctionTemplate> objectTemplate = Nan::New<v8::FunctionTemplate>();
objectTemplate->SetClassName(Nan::New("Vector3").ToLocalChecked());
objectTemplate->InstanceTemplate()->SetInternalFieldCount(1);
constructor.Reset(objectTemplate->GetFunction());
}
v8::Local<v8::Object> Vector3::WrapObject(double* components) // Static
{
v8::Local<v8::Function> constructorFunction = Nan::New(Vector3::constructor);
v8::Local<v8::Object> localObject = Nan::NewInstance(constructorFunction).ToLocalChecked();
Nan::Set(localObject, Nan::New("X").ToLocalChecked(), Nan::New<v8::Number>(components[0]));
Nan::Set(localObject, Nan::New("Y").ToLocalChecked(), Nan::New<v8::Number>(components[1]));
Nan::Set(localObject, Nan::New("Z").ToLocalChecked(), Nan::New<v8::Number>(components[2]));
return localObject;
}
The full code is a bit more complex as each vector is a property of some wrapped entity class.
From reading the many online tutorials and posts it seems like this is one of the most common ways to wrap an object, however, is there any faster way?
Profiling the code highlights Nan::Set as a major bottleneck. In particular, it seems Set internally calls two v8 methods:
v8::internal::Object::SetProperty
and
v8::internal::LookupIterator::PropertyOrElement
with each method taking up about 50% of the total Set function.
So my thoughts are:
Is there anyway to bypass the lookup function and call SetProperty directly?
Surely the lookup step is redundant here as I know ahead of time that I am setting a property and not an element.
Is there perhaps a way to define the properties on the object template in the Initialise method and then just set them using some integer index (while still retaining them as named properties and not elements) rather than the string name so the lookup is faster?
Is there any way to set multiple properties on an object at the same time?
Is there a better method entirely?

Name for pattern T | Array<T>

A common pattern that libraries use is accepting a type or an array of that type as an argument to a function. For example:
interface JQuery {
add(selector: HTMLElement | HTMLElement[]): this;
}
Is there a name for this pattern? I'd like to alias it to improve readability. My first guess is TypeOrArray<T> but this sounds clunky and may potentially be unintuitive.
Note: I've tagged this typescript since that's what I'm using and something idiomatic may be a better answer. However, this should apply to any language that makes use of generics.

That syntax is typescript's way of allowing you to define multiple types for a single parameter.
In your case the selector can be either an HTMLElement or an Array of HTMLElement.
The same you can do for any type:
function example(parameter: number | string) {
}
example(5) // works
example('2') // works
example(new Date()) // fails

I don't think the pattern actually is "type or array of the type".
It's more like "whatever the author of the library considered to be convenient for its users".
Typescript union type fits pretty good here, it allows you to describe whatever combination of types is acceptable for particular function, without thinking too much about names.
If you inclined to name your types, the appropriate name could be
type HTMLElementsToAdd = HTMLElement | HTMLElement[];
The purpose is to indicate that the type is not just an element array, and is specific to add method. Cursory look through jQuery API docs confirms that it hardly follows any specific pattern, and actually uses "or" to describe acceptable types, for example:
.append( content [, content ] )
content
Type: htmlString or Element or Text or Array or jQuery

Generate JSON-patch from two objects

Given two Javascript objects (A and B), is there a way to generate the JSON patch, so that when that patch is applied to A it would change the object's properties to that of object B?
For example, given hypothetical JSONPatch function (perhaps being a function of similar name to one of those linked below), what is desired is the generate_patch function.
patch = generate_patch(A, B)
JSONPatch.apply(patch, A) # modifies A so that it has the same properties as B.
In this question A and B are Javascript objects. A patch created by RFC6902 is JSON that would indicate an array of operations which when applied to A that object would become B. The generate_patch function need not return JSON though, rather for efficiency could return a Javascript object that becomes the RFC6902 JSON-patch document when JSON.stringify is called on it.
The projects I have found on the topic are:
https://github.com/bruth/jsonpatch-js - only patches (does not generate a patch)
http://jsonpatchjs.com/ - same
https://github.com/Starcounter-Jack/Fast-JSON-Patch - observes an object, does not take two different objects

Turning my comment into an answer...
This code https://www.npmjs.org/package/rfc6902 seems to be a full javascript implementation of both patch and diff for the stated RFC.
I haven't used it myself, but the documentation makes it look like what you asked for.

Since version 0.3.9, https://github.com/Starcounter-Jack/Fast-JSON-Patch has a compare method which returns a difference between 2 objects. If I understand correctly, that may be what you were looking for

I have also written a library to generate patches: https://github.com/gregsexton/json-patch-gen
I found out about 'rfc6902' after having written and used json-patch-gen. I'm not sure how they compare: it may be worth trying out both to see if one fits your needs better.

What is the Python best practice concerning dicts vs objects for simple key-value storage?

After some time programming in Javascript I have grown a little fond of the duality there between objects and associative arrays (dictionaries):
//Javascript
var stuff = { a: 17, b: 42 };
stuff.a; //direct access (good sugar for basic use)
stuff['a']; //key based access (good for flexibility and for foreach loops)
In python there are basically two ways to do this kind of thing (as far as I know)
Dictionaries:
stuff = { 'a': 17, 'b':42 };
# no direct access :(
stuff['a'] #key based access
or Objects:
#use a dummy class since instantiating object does not let me set things
class O(object):
pass
stuff = O()
stuff.a = 17
stuff.a = 42
stuff.a #direct access :)
getattr(stuff, 'a') #key based access
edit: Some responses also mention namedtuples as a buitin way to create lighweight classes for immutable objects.
So my questions are:
Are there any established best-practices regarding whether I should use dicts or objects for storing simple, method-less key-value pairs?
I can imagine there are many ways to create little helper classes to make the object approach less ugly (for example, something that receives a dict on the constructor and then overrides __getattribute__). Is it a good idea or am I over-thinking it?
If this is a good thing to do, what would be the nicest approach? Also, would there be any good Python projects using said approach that I might take inspiration from?

Not sure about "established best practices", but what I do is:
If the value types are homogenous – i.e. all values in the mappings are numbers, use a dict.
If the values are heterogenous, and if the mapping always has a given more or less constant set of keys, use an object. (Preferrably use an actual class, since this smells a lot like a data type.)
If the values are heterogenous, but the keys in the mapping change, flip a coin. I'm not sure how often this pattern comes up with Python, dictionaries like this notably appear in Javascript to "fake" functions with keyword arguments. Python already has those, and **kwargs is a dict, so I'd go with dicts.
Or to put it another way, represent instances of data types with objects. Represent ad-hoc or temporary mappings with dicts. Swallow having to use the ['key'] syntax – making Python feel like Javascript just feels forced to me.

This would be how I decide between a dict and an object for storing simple, method-less key-value pairs:
Do I need to iterate over my key-value pairs?
Yes: use a dict
No: go to 2.
How many keys am I going to have?
A lot: use a dict
A few: go to 3.
Are the key names important?
No: use a dict
Yes: go to 4.
Do I wish to set in stone once and forever this important key names?
No: use a dict
Yes: use an object
It may also be interesting to tale a look at the difference shown by dis:
>>> def dictf(d):
... d['apple'] = 'red'
... return d['apple']
...
>>> def objf(ob):
... ob.apple = 'red'
... return ob.apple
...
>>> dis.dis(dictf)
2 0 LOAD_CONST 1 ('red')
3 LOAD_FAST 0 (d)
6 LOAD_CONST 2 ('apple')
9 STORE_SUBSCR
3 10 LOAD_FAST 0 (d)
13 LOAD_CONST 2 ('apple')
16 BINARY_SUBSCR
17 RETURN_VALUE
>>> dis.dis(objf)
2 0 LOAD_CONST 1 ('red')
3 LOAD_FAST 0 (ob)
6 STORE_ATTR 0 (apple)
3 9 LOAD_FAST 0 (ob)
12 LOAD_ATTR 0 (apple)
15 RETURN_VALUE

Well, if the keys are known ahead of time (or actually, even not, really), you can use named tuples, which are basically easily-created objects with whatever fields you choose. The main constraint is that you have to know all of the keys at the time you create the tuple class, and they are immutable (but you can get an updated copy).
http://docs.python.org/library/collections.html#collections.namedtuple
In addition, you could almost certainly create a class that allows you to create properties dynamically.

Well, the two approaches are closely related! When you do
stuff.a
you're really accessing
stulff.__dict__['a']
Similarly, you can subclass dict to make __getattr__ return the same as __getitem__ and so stuff.a will also work for your dict subclass.
The object approach is often convenient and useful when you know that the keys in your mapping will all be simple strings that are valid Python identifiers. If you have more complex keys, then you need a "real" mapping.
You should of course also use objects when you need more than a simple mapping. This "more" would normally be extra state or extra computations on the returned values.
You should also consider how others will use your stuff objects. If they know it's a simple dict, then they also know that they can call stuff.update(other_stuff) etc. That's not so clear if you give them back an object. Basically: if you think they need to manipulate the keys and values of your stuff like a normal dict, then you should probably make it a dict.
As for the most "pythonic" way to do this, then I can only say that I've seen libraries use both approaches:
The BeautifulSoup library parses HTML and hands you back some very dynamic objects where both attribute and item access have special meanings.
They could have chosen to give back dict objects instead, but there there is a lot of extra state associated with each object and so it makes perfect sense to use a real class.
There are of course also lots of libraries that simply give back normal dict objects — they are the bread and butter of many Python programs.

How do modern browsers implement JS Array, specifically adding elements?

By this I mean when calling .push() on an Array object and JavaScript increases the capacity (in number of elements) of the underlying "array". Also, if there is a good resource for finding this sort of information for JS, that would be helpful to include.
edit
It seems that the JS Array is like an object literal with special properties. However, I'm interested in a lower level of detail--how browsers implement this in their respective JS engines.

There cannot be any single correct answer to this qurstion. An array's mechanism for expanding is an internal implementation detail and can vary from one JS implementation to another. In fact, the Tamarin engine has two different implementations used internally for arrays depending on if it determines if the array is going to be sequential or sparse.

This answer is wrong. Please see #Samuel Neff's answer and the following resources:
http://news.qooxdoo.org/javascript-array-performance-oddities-characteristics
http://jsperf.com/array-popuplation-direction
Arrays in JavaScript don't have a capacity since they aren't real arrays. They're actually just object hashes with a length property and properties of "0", "1", "2", etc. When you do .push() on an array, it effectively does:
ary[ ary.length++ ] = the_new_element; // set via hash

Javascript does include a mechanism to declare the length of your array like:
var foo = new Array(3);
alert(foo.length); // alerts 3
But since arrays are dynamic in javascript there is no reason to do this, you don't have to manually allocate your arrays. The above example does not create a fixed length array, just initializes it with 3 undefined elements.
// Edit: I either misread your question or you changed it, sorry I don't think this is what you were asking.