Use get for all Dust references

[smfoote]

dot-notation references will now use get, and getPath is deprecated.

Also in this commit:

• Update to version 2.2.0
• When get returns a function, add an isFunction attribute to the returned function and set it to true. This fixes the bug that was causing dustjs-helpers tests to fail.

[smfoote]

Currently merging changes. Will update PR shortly.

[smfoote]

This is one of the lines that actually changed.

[prashn64]

lgtm, let's get another pair of eyes on it before we merge.

[rragan]

Let me step back and ask why do this?

get/getPath is a mostly internal interface (barring helpers) between the compiler and the dust runtime. Other than refactoring to consolidate to one routine what does this gain us? I guess it might slow down get and getPath each a bit as they were specialized for their own cases before. It's not like we can get rid of getPath either for a long time due to use by helpers so download size will presumably get larger.

[smfoote]

The reason for this change is actually based on a bug in the dustjs-helpers repo. As we were trying to debug, we tracked the problem down to the get method. However, the method was very difficult to understand as it was written. As I rewrote it, I found the source of the bug (PR to be added to the dustjs-helpers repo after this PR is merged).

The new get method only adds a few steps beyond what the previous get method included for references without dots. It is still optimized for the no-dot reference use case.

Finally, the new version will reduce the total amount of code, because the getPath method now just points to the get method.

In summary, this change (1) makes get easier to understand and maintain, (2) fixes a bug in dustjs-helpers, (3) reduces the total size of the library (slightly), and (4) is backward compatible.

[jimmyhchan]

does this pass the tests added in #357 it would be good to fix this once.

[rragan]

See also my comment/proposed fix on #340. This should also be verified to be OK.

[smfoote]

I added the tests from #357 and all tests pass. I think the issue in #340 is separate enough that it should be a different pull request.

[rragan]

Thanks for covering #357. Agree #340 should be separate

[jimmyhchan]

As discussed let's address a few issues:

• context.get('key') should be the API ... having to pass false as the first argument is not nice.
• should we support context.get('key.with.dots')

I think we agree the API should be intuitive and simple and the compiler output should be fast and direct..... not sure what the best solution is.

[jimmyhchan]

the dist file seems to be out of date. did you make?

[jimmyhchan]

thanks for the fixes. This looks good.
@rragan how does this look to you?

[rragan]

Just this one question:

In _get, this bit of code:
if (typeof arguments[0] === 'string') {
// For backwards compatability, if the first argument is a string, make that string the
// first item in the down array.
down = [arguments[0]];
cur = false;
}

_get is a new private function so presumably no one is calling it directly from old code. The actual get function, seems to ensure cur is a boolean.
When would the if test for "string" ever be true? Legacy getPath always had a boolean as the first argument too (unless there is some edge case I don't remember). Is this code needed?

[smfoote]

Good point. It's not needed anymore.