Suggestion - Support Extending Objects

[Albert-IV]

It would be pretty awesome if there was a way of using dottie to extend the native Object prototype. I suggest this because there's a lot of verboicity in dottie.get(obj, 'some.property').

dottie.extend();
// Extends Object prototype

var values = {
  some: {
    nested: {
        key: 'foobar';
    }
  }
}

values.dGet('some.nested.key'); // returns 'foobar'
values.dGet('some.undefined.key') // returns undefined

values.dSet('some.nested.value', someValue);  // creates nested structure


var somePostData = {
  'user.name': 'Gummy Bear',
  'user.email': '[email protected]',
  'user.professional.title': 'King',
  'user.professional.employer': 'Candy Mountain'
};

var transformed = somePostData.dTransform();

var somePostData = {
  'user_name' : 'Mick Hansen',
  'user_email' : '[email protected]'
};

var delimited = somePostData.transform({ delimiter: "_" });

If you're OK with doing something like this I can start writing the extension code.

[mickhansen]

Extending native objects in javascript is usually frowned upon. It introduces issue with enumerability etc, but i suppose that could be worked around with defneProperty in newer javascript version.

Another solution could be to create a wrapper ala:

var values = dottie.wrap({
  some: {
    nested: {
        key: 'foobar';
    }
  }
});

Although that would probably kill normal object access.

[mickhansen]

http://sugarjs.com/native

[Albert-IV]

Yeah, I was thinking of using defineProperty to ensure it was non-enumerable and throwing or returning an Error if dottie.extend() is called in an unsupported environment.

We could also get fancy and have the users specify what properties the .extend() call would set those helpers to, so users don't have data locations overwritten unexpectedly.

dottie.extend({
  // <dottie call> : <extension property>
  get : 'dottieGetMethod',
  set : 'dottieSetMethod'
  // etc
})

obj.dottieGetMethod('some.property')

Extending the native Object is frowned upon by some people, but not all. Most of the problems people have with extending native stuff comes from people trying to extend DOM objects (which has a bunch of issues depending on the browser).

That's why I was wanting it to be an optional .extend() call rather than default behavior (it isn't optimal in a bunch of use-cases).

[mickhansen]

Yeah as long as we make the extension explicit and optional i'm all for.

Perhaps the default method names should me obj.$get, obj.$set etc - Same short names but most likely no clashes.

[Albert-IV]

Sure, we can have the defaults be $ by default.

I'm not against adding the dottie.wrap(<object>) syntax either. We could use that as a single-object extension, or alternatively a helper that allows you to use .get() .set() syntax to return/ alter values from the wrapped object. How do you think we should handle those sort of calls?

Since we're good with dottie.extend(), I'll start with adding with the syntax into a PR. Let me know what you think about how .wrap() should work.