datastore: scope Key creation to include NS. fixes #116.

RE: #116

I actually have 2 different implementations for this, but this was the one I thought was the most logical.

When a user creates a dataset, they can provide a namespace. Then, anytime they need a key, instead of `datastore.key()`, they call `datasetInstance.key()` - the key will be created with the namespace already bound to the Key.

The other implementation removed any association of a namespace from a Key object, which [felt wrong](https://developers.google.com/datastore/docs/apis/v1beta2/key).

PTAL & LMKWYT.
I'm not sure which context Nick's comment is about, but it's not related to
the case here. Because our constructor expects a value for both args.

You don't initialise an object with undefined. It's undefined only if it
happens to be undefined -- like a third argument which has not been
provided.

In our case, we always expect a value for namespace (null or string), so I
don't understand why we do cast it to undefined.


On Thu, Aug 21, 2014 at 5:09 PM, Stephen Sawchuk <notifications@github.com>
wrote:

> In lib/datastore/query.js:
>
> > @@ -38,7 +42,7 @@ var util = require('../common/util.js');
> >   * ```
> >   */
> >  function Query(namespace, kinds) {
> > -  this.namespace = namespace;
> > +  this.namespace = namespace || '';
>
> I worded my analogy wrong. It's really more like this:
>
> "When defining a variable that is meant to later hold an object, it is
> advisable to initialize the variable to null as opposed to anything else.
> That way, you can explicitly check for the value null to determine if the
> variable has been filled with an object reference at a later time"
> - Nick Zakas
> <http://stackoverflow.com/questions/6604749/what-reason-is-there-to-use-null-instead-of-undefined-in-javascript>
>
> Where we expect a string, if one isn't provided, we cast it to undefined,
> as we didn't receive the string we expected. The significance is what the
> value provided to the Query constructor means in the context of a Query. If
> it's null, undefined, empty string, 0, or anything that's not a legitimate
> string value, it means "undefined", user didn't define a namespace. Inside
> the Query.prototype methods, we're simple casting to a boolean, so any of
> the above will work the same.
>
> In the end, there really is no reason to use null vs undefined vs 0 vs
> false (etc etc) in a case like this, except for convention and preference.
> I prefer to stick to the convention, but will happily go null if you wish. [image:
> :+1:]
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/GoogleCloudPlatform/gcloud-node/pull/124/files#r16576830>
> .
>



-- 
Burcu Dogan