A middleware script that seeks to allow functions in local javascript to be automatically wrapped in custom code wrappers. These can then be used to aid profiling/error checking/code understanding.
The original concept for Wares were custom snippets of code that could be auto-inserted before and after functions were called in a Wrapper.
This had a number of advantages:
Wares could be created, registered to a function, and run during code execution at runtime.
Wares help vAnalyze meet its concern with on-the-fly debugging. When you want to check for something, you write a quick Ware for it, register it, and then immediately all of your functions start running that code instantly.
With some of the more recent API changes, Wares require a bit of rethought. Specifically:
How expansive should they be? Should internal structures (like the Stack) be defined via Wares?
How are Hosts and Wrappers going to manage globally shared data? I'd like to avoid using the global scope at all if possible.
What tools need to exist for Wares to function correctly? How are they scoped and how does the user specify which functions are running which Wares.
This will likely be the next API that needs to be finalized, because a number of other questions depend on it: notably the stack, but also some smaller stuff like watching properties and having functions trigger events.
I think, at the moment, the dependency list for this, and the order of attack, should be something like:
resolving global scope
resolving wares
implementing stack / property watching
The stack is going to be it's own arc probably, since I'm interested in doing things like storing and exposing call history for functions. I likely won't get into that here, except to think of how it influences the most immediate decisions.
The original concept for Wares were custom snippets of code that could be auto-inserted before and after functions were called in a Wrapper.
This had a number of advantages:
With some of the more recent API changes, Wares require a bit of rethought. Specifically:
This will likely be the next API that needs to be finalized, because a number of other questions depend on it: notably the stack, but also some smaller stuff like watching properties and having functions trigger events.
I think, at the moment, the dependency list for this, and the order of attack, should be something like:
The stack is going to be it's own arc probably, since I'm interested in doing things like storing and exposing call history for functions. I likely won't get into that here, except to think of how it influences the most immediate decisions.