possible conflicts between user method names and DSL method names

[paciorek]

In working on a new sampler, we used setSize as a method name, but it caused a conflict in compilation because of our native setSize.

At some point we might want to add a check that catches such name conflicts.

[paciorek]

A few more notes here.

It looks like the problematic method names are those for which cppOutputCalls assigns cppOutputMemberFunction.

names(cppOutputCalls[cppOutputCalls == 'cppOutputMemberFunction']) [1] "matrix" "array" "setSize" "initialize"
[5] "getPtr" "dim" "getOffset" "strides"
[9] "isMap" "mapCopy" "setMap" "startNimbleTimer" [13] "endNimbleTimer" "push_back" "resizeNoPtr"

Also those where cppOutputCalls assigns cppOutputEigMemberFunction or cppOutputEigExternalUnaryFunction and probably some other situations.

However, I am also wondering if we are processing things like floor that overlap with math functions in the way that we want. Or if we just are getting lucky that a method name like floor gets passed through without problems.

Also method names with periods cause problems, not surprisingly.

Would be good to discuss with @perrydv . Not a very high priority, but there are enough standard names that are not ok that we probably don't want to ignore this.

One possible easy hack would be to trap the final error Error in code$args[[1]] : subscript out of bounds when it occurs in nimGenerateCpp and report that that method name can't be used.