Architectural Issues - mslegrand/svgR GitHub Wiki

Elements are not exported

In order to prevent name space pollution, element functions are not exported, but rather to be used in the scope of an svgR call. This has ramifications that creates the following issues

Evaluation of an svgR Call

1 A call with parameters not involving Elements

Parameters not involving elements need to be evaluated in the calling environment

2 A svgR call with parameters that are Elements

Since the elements are not exported, evaluation of parameters which are elements must be performed within the svgR package environment. And in particular, any name which is a name for an element must be iterpreted as an element. Thus rect, filter, are to be consider elements from svgR and not from other packages.

Currently a merge of the two environments are used for eval, but complexities can occur which I may not have anticipated. (I will revisit this in the next iteration). Things might have been simpler, had we only required that parameters not involving elements be from the global environment.

3 A call with parameters that are external functions whose body contains Elements

Again elements are not exported: Thus functions external to the scope of svgR that reference elements need special care. Two obvious approaches are possible:

• quote the function, and evaluate within the scope of svgR
• wrap the function, to give it access to elements.

Both approaches have downsides. (a more elaborate discussion is probably warranted.)

Completions

Completions are problematic since the elements are not exported. Named arguments (parameters) can be explicitly added via utils:::.addFunctionInfo, but how to handle unnamed parameters (ie. elements) is still a mystery.