put context caching functionality under context.cache

(adapted from https://github.com/Microsoft/botbuilder-js/issues/66#issuecomment-368210787)

Let’s put the context cache functionality under the name context.Cache (.net, where it would presumably be a Dictionary), and context.cache (JS, where it would be a Map):

C#

if (context.Cache.ContainsKey("myKey")) {
    value = context.Cache["myKey"};
    context.Cache.Remove("myKey");
}

JavaScript

if (context.cache.has("mykey")) {
    value = context.cache.get("myKey");
    context.cache.delete("myKey");
}

This strikes a better balance between common naming across SDKs and language-specific idiom.

In the current JS implementation, context just exposes get/has/set - functions, which by themselves don’t telegraph much about their purpose. This puts them behind a meaningful identifier.

Most bot developers will never used the cache directly, and this reduces the surface area of context (the list that pops up under intellisense).

Finally, by exposing the underlying object directly, the technical debt of this feature goes down.

[billba]

There were several instances from this week’s hack where people tried to use context.set/.get for the “wrong” thing. The more descriptively we can name this, e.g. context.serviceCache, the more likely it won’t be abused.

I also think we could go further and explore even more verbosity. My favorite method name in the world (doesn’t everyone have a favorite method name?) is React’s dangerouslySetInnerHTML because it’s wildly descriptive: you can set the HTML but you should think twice and probably Google to see what’s so dangerous. So maybe something like context.cacheReallyJustForServices. It sounds like a joke, but if it forces people to look it up then its accomplished its goals.

[billba]

I don’t understand your comment - this DCR – which was not about state – was adopted in full (we eventually settled on context.service/context.Service).