-
Notifications
You must be signed in to change notification settings - Fork 17
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
Naming of function names (in R) #11
Comments
Personally I don't see this as a real issue. We are currently using the detailed process description to get relevant information about the process and its arguments (the name of the process and the names of the arguments). To build the process graph we use basic functions |
The previous discussion: @edzer wrote:
@GreatEmerald wrote:
@edzer wrote:
m-mohr wrote:
@nuest wrote (mentioned above):
|
I'd agree with @flahn that it's not a big deal at the moment. If we were to define functions for each process (the way the Python client does at the moment AFAIK), we start running into what is effectively the question of profiles: which, if any, processes should be "mandatory" for openEO backends? Or which of them should be in a "core" openEO profile? There will probably be backends that don't implement all the processes in the core profile, anyway (AWS, for instance). And then you'd get Perhaps in the long run, once we see which backends implement which processes, having a function for each popular one would be an option. But I'd say it's too soon now. @nuest On the Swagger codegen: I don't think this helps for the process definitions. Those are defined on each backend, not part of the core API. |
This is kind of a design choice. If we want to define separate (standalone) functions for each process, then we would store each function in the global environment. The benefit would be that you will see every function offered by the backend as a function variable in the global environment. The drawback is almost the same, you will see ALL the functions offered by the backend in the global environment...
The idea of an "openeo core profile" we have already discussed at WWU and it seems a promosing approach. And for those it probably makes sense to have predefined functions. But as you said, this is a discussion for later. |
Yea, indeed, the standard practice is for packages to not pollute the environment. Name collisions is another problem, if the user had a variable called R is nice with the support for function signatures, though: if we define a task as an object of type But yes, I could see that being implemented if we have a core profile. Maybe it would make sense to also discuss the profiles idea in a separate issue? |
The core profile is discussed here: Open-EO/openeo-api#2 |
Ha, yes, I just noticed that myself :) |
In order to have an easier way to formulate processes, I have implemented a process graph builder. If you are using RStudio or another IDE for R with autocompletion you get suggestions what function is available and which Arguments are allowed by the backend. The way it work: when creating the process graph builder, we first query the backend for all offered processes Look here for more information. |
That's pretty neat, but it still results in an R6 object rather than a regular S3 function. Though that does make the functions self-contained and specific for a particular connection, so perhaps in this case it's worth the weird semantics of calling functions inside objects... |
Splitting an off-topic discussion from Open-EO/openeo-api#47 into this issue.
from @nuest Re (3): Have you considered generating the functions in the R package from the API spec? See https://github.com/richfitz/stevedore/blob/master/R/swagger_args.R
The text was updated successfully, but these errors were encountered: