You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That might get complicated to explain and maintain. I think features should be functions only, and map_dep() should be a generic function that is always called after get_.
E.g.:
mica %>%
get_n_obs() %>%
map_dep()
That way, users call a get_ function first (and can explore the data at that stage), but have the option to pipe it further to see that dataframe as a map.
The text was updated successfully, but these errors were encountered:
@jimcasaer: I discussed this with @peterdesmet of course and I find a good idea as well. What do you think? I think this will give a very boost to the package (especially if combined with #92) as it will make things easier to understand and follow. Users will have to use explicitly the get_* functions, I know, but they will get rid of the argument feature in map_dep(). At least in the new approach they will be helped by autocompletion while writing the function name, while they are not while selecting the feature in map_dep().
This will also very clearly split the calculation and the visualization part. Good for both users and software quality.
Currently features are implemented in two ways:
get_n_obs(mica)
map_dep(mica, feature = "n_obs")
That might get complicated to explain and maintain. I think features should be functions only, and
map_dep()
should be a generic function that is always called afterget_
.E.g.:
That way, users call a
get_
function first (and can explore the data at that stage), but have the option to pipe it further to see that dataframe as a map.The text was updated successfully, but these errors were encountered: