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

print() support for variable arguments #181

Open
jeremydouglass opened this issue Jul 21, 2017 · 5 comments
Open

print() support for variable arguments #181

jeremydouglass opened this issue Jul 21, 2017 · 5 comments

Comments

@jeremydouglass
Copy link
Member

#176 adds support for redirecting print() to console -- this works well for one argument.

In Processing(Java), print supports varargs -- e.g. void print(Object... arg){}, like this:

print("a", 1, "b", mouseX);

a 1 b 75

You can see it in the docs here:

Two questions:

  1. How hard would it be to support this in Processing.R? It isn't high priority, but it is common when logging to write for example print(mouseX, mouseY);
  2. If it could be supported, what is the most natural way to write varargs variable length argument lists in R? Would it just be print("a", 1, "b", mouseX)?
@gaocegege
Copy link
Member

I am not familiar with the print system in R, so I need to try it.

@jeremydouglass
Copy link
Member Author

This looks complex.

The R native print method:

print.default() is the default method for the S3 generic print() function. That means that to call print.default(), you just call print() on an object that doesn't have its own print() method. https://www.rdocumentation.org/packages/base/versions/3.4.1/topics/print.default

... is then mapped by renjin like this:

https://github.com/bedatadriven/renjin/blob/master/core/src/main/java/org/renjin/primitives/Print.java

So the question is, should Processing.R mode be giving full access to the Processing(Java) print() method -- which uses varargs -- or should it be using the native R print() -- which accepts a single object, but that object can be a vector or a complex data frame?

@gaocegege
Copy link
Member

I think P.R should support these two ways, since The users comes from both Processing and R community.

@jeremydouglass
Copy link
Member Author

jeremydouglass commented Jul 28, 2017

Interesting. Supporting both methods would either require:

  1. multiple signatures for print that could detect a data primitive vs. vector / data frame vs. varargs, or
  2. renaming one of print methods -- for example "print / pprint" for Processing-print, or "print / rprint" for R-print.

Which approach do you think makes more sense? Or is there another approach?

@gaocegege gaocegege modified the milestone: v1.0.6 Aug 31, 2017
@jeremydouglass
Copy link
Member Author

Thinking about this further, I think that "print" in R mode should be left in an R-native style -- it takes a single object, which may be a vector.

To make this easier for learners, I could:

  1. generate a helpful warning message about how to use vector-style if print() is given the wrong number of arguments. This would particularly help people who are cut-pasting Java mode or python mode sketches into R-mode and trying to adapt them one error at a time.

  2. update the documentation to explain usage at https://processing-r.github.io/reference/print.html

@jeremydouglass jeremydouglass added this to the v1.0.8 milestone Aug 6, 2019
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

2 participants