From dfacf08e45934d0999b175c2be70f9a8495abbb5 Mon Sep 17 00:00:00 2001
From: Victor Woeltjen <victor.woeltjen@nasa.gov>
Date: Wed, 19 Aug 2015 13:44:34 -0700
Subject: [PATCH] [API] Propose registering instances

WTD-1237
---
 docs/src/design/proposals/APIRedesign.md | 33 ++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/docs/src/design/proposals/APIRedesign.md b/docs/src/design/proposals/APIRedesign.md
index 42c3b6269e..77a0159aad 100644
--- a/docs/src/design/proposals/APIRedesign.md
+++ b/docs/src/design/proposals/APIRedesign.md
@@ -751,3 +751,36 @@ JSDoc.)
 ### Detriments
 
 * Increases documentation burden.
+
+## Register Extensions as Instances instead of Constructors
+
+Register extensions as object instances instead of constructors.
+This allows for API flexibility w.r.t. constructor signatures
+(and avoids the need for partial constructors) and additionally
+makes it easier to provide platform implementations of extensions
+that can be used, subclassed, etc.
+
+For instance, instead of taking an `ActionContext` in its
+constructor, an `Action` would be instantiated once and would
+accept appropriate arguments to its methods:
+
+```js
+function SomeAction {
+}
+SomeAction.prototype.canHandle = function (actionContext) {
+    // Check if we can handle this context
+};
+SomeAction.prototype.perform = function (actionContext) {
+    // Perform this action, in this context
+};
+```
+
+### Benefits
+
+* Reduces scope of interfaces to understand (don't need to know
+  what constructor signature to provide for compatibility.)
+
+### Detriments
+
+* Requires refactoring of various types; may result in some
+  awkward APIs or extra factory interfaces.