Skip to content

Renaming #16

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

Closed
lorenzwalthert opened this issue Jun 1, 2017 · 11 comments
Closed

Renaming #16

lorenzwalthert opened this issue Jun 1, 2017 · 11 comments

Comments

@lorenzwalthert
Copy link
Collaborator

Naming of data

At the moment, for the parse table returned by utils::getParseData and
processed through various functions, we use many different names in different
functions for essentially this (flat) table:

  • pd (all rules in rules.R)
  • parse_data (serialize_parse_data)
  • parse_data_with_ws (serialize_parse_data_flat)
  • data (create_filler)

I think it would simplify things to just use one variable name throughout. I
suggest parse_data. We could use parse_data_flt for the flat version and and
parse_data_nstd for the nested version for situations where the processing
differs.

Naming of functions

As far as I understand, the terminology around ws is more of a legacy thing, i.e. in the functions compute_parse_data_flat_with_ws or add_ws_to_parse_data since it is not really just white space information that is affected by these functions, but rather a bunch of preprocessing Hence, I would suggest to rename the latter to pre_process_parse_data and the former to compute_parse_data_flt for now.

@krlmlr
Copy link
Member

krlmlr commented Jun 1, 2017

A consistent name is a good idea. Can we simply use nested and flat, or perhaps standardize on pd for parse data and use this as a prefix or suffix?

@lorenzwalthert
Copy link
Collaborator Author

Ok yes, let us just use pd then and use flat and nested as suffix.

@lorenzwalthert
Copy link
Collaborator Author

Reference: #146 (comment).

@lorenzwalthert
Copy link
Collaborator Author

So as stated in #146 (comment), should we use nest for "a parse table at one level of nesting, which always represents a complete expression", and pd_nested for the whole nested structure, i.e. the parse table at the top level of nesting?

@lorenzwalthert
Copy link
Collaborator Author

This includes documentation also obviously.

@krlmlr
Copy link
Member

krlmlr commented Aug 23, 2017

Yes, we can keep the terms "parse data" and "nested parse data" for simplicity. The latter consists of multiple interlinked nests, this is the only new term.

@lorenzwalthert
Copy link
Collaborator Author

Reference: #132.

@lorenzwalthert
Copy link
Collaborator Author

lorenzwalthert commented Sep 30, 2017

Renaming of files

  • modify_pd.R -> indent.R
  • nested.R -> nest.R
  • ws.R -> ui.R
  • style_md.R -> transform-code.R.
  • transform.R -> transform-files.R

@krlmlr
Copy link
Member

krlmlr commented Oct 23, 2017

Do we need to change anything here, short of renaming the files as you suggested?

@lorenzwalthert
Copy link
Collaborator Author

Seems no, if we want to leave the rest (pd, pd_flat, pd_nested etc.) as is. However, I think we should change it too for consistency. Not all of it though, e.g. flattened_pd is not a nest anymore.

@lorenzwalthert lorenzwalthert added this to the CRAN milestone Nov 2, 2017
lorenzwalthert referenced this issue in lorenzwalthert/styler Nov 2, 2017
lorenzwalthert referenced this issue in lorenzwalthert/styler Nov 8, 2017
lorenzwalthert referenced this issue in lorenzwalthert/styler Nov 8, 2017
@lorenzwalthert
Copy link
Collaborator Author

lorenzwalthert commented Nov 26, 2017

  • serialized_tests.R to serialized-tests.R
  • style_guides.R to style-guides.R
  • move stop_insufficient_r_version() to communicate.
  • dplyr.R to compat-dplyr.R
  • consistency: is_fun_dec() or pd_is_fun_dec() in expr-is.R

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