Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to pass a context reference through to visitor interface callbacks... #44

Open
ChrisRus opened this issue Jul 21, 2015 · 1 comment
Assignees

Comments

@ChrisRus
Copy link
Member

Developers are currently forced to manage any context their visitor interfaces require above and beyond the context provided by the request object passed to each callback by the algorithm. Typically, developers leverage a JavaScript closure scope and define their visitor object and invocation of the jsgraph algorithm in that scope.

For example, it is typical that visitor interface function implementations record information that is required in part or in whole to produce the result of the operation. Currently, it is assumed that developers will take care of this detail on their own.

cycleEdges = [];
var dftVisitor = {
    forwardOrCrossEdge: function(request) {
        cyclesEdges.push(request.e); // record the edge
        // What I want is rather: request.context.cyclesEdges.push(request.e);
       return true; // continue the traversal
    }
};
var response = jsgraph.directed.depthFirstTraverse({ digraph: digraph, visitor: dftVisitor });
if (response.error) {
    throw new Error(response.error); // e.g.
}
if (cycleEdges.length) {
    console.log("Digraph contains cycles on the following edges: " + JSON.stringify(cycleEdges) );
}

'''

However, in more advanced scenarios it would be helpful to have a standard way to direct visitor interfaces to a specific sandbox for keeping track of intermediate state and building results.

Make it possible to pass a context reference via traversal algorithm request object that gets passed to visitor callbacks. This will allow the algorithm caller far more flexibility and control than is now convenient.

@ChrisRus ChrisRus self-assigned this Jul 21, 2015
@ChrisRus ChrisRus added this to the v0.5.30 milestone Jul 21, 2015
@ChrisRus ChrisRus removed this from the v0.5.30 milestone Nov 18, 2015
@ChrisRus
Copy link
Member Author

Nice to have but not critical enough to invest the time to test the solution right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant