PCA related functions

[Lars Skjærven]

after the inclusion of pca() I think we should rename function pca.project since R will now assume this is a part of the pca generic functions. better with project.pca ? perhaps also something similar for function pca.z2xyz. hmmm...

S3 methods shown with full name in documentation object 'pca.project': ‘pca.project’ ‘pca.z2xyz’ ‘pca.xyz2z’

S3 methods shown with full name in documentation object 'pca.tor': ‘pca.tor’

[Xinqiu Yao]

It will be a big change, affecting many example codes, tutorials, vignettes, and working scripts. Also, we need a "tor" class of object for using pca.tor() properly for torsion angle PCA. Should we change them now or we leave them until a major version update? It seems only show warnings in R CMD check and doesn't affect functioning of the package. Am I correct?

[Lars Skjærven]

not sure how much CRAN would complain about something like this. would be good to get things consistent though.

[Barry Grant]

Yes I had this worry with the pca.xyz() switch. I would like to leave these alone for now (i.e. next release, as we have lots of changes already) but come up with a consistent naming convention for future functions and future slow migration of these guys.

I guess functions should be in the mode of "actionOfFunction.object2workOn()" i.e. "project.pca()", seq.pdb(), etc. The last example here is a problem and one we had to change the naming order which annoyed me and breaks this convention. Reversing the order would have the advantage of having potentially related functionality alphabetically close in function lists but makes less sense. What do others think?

[Xinqiu Yao]

I like the naming convention "actionOfFunction.oject2workOn()". But for most functions current names are fine to me, e.g. "atom.select" (it would be selectatom.pdb by the convention). We need only to change names of functions that already cause problems, such as pca.project and pca.z2xyz, in next release. Also, in future development, I recommend that for new functions we always start with a simple name, i.e. indicating action and without dot. By this, we can gradually add new object class for the method without breaking the convention and, more importantly, be back-compatible.

[Barry Grant]

Good point about the dot - I took this decision back when I used ESS through emacs, which hated underscores. I am also not a fan of mixed upper case lower case names such as pcaProject() as I end up mistyping these easily.

So did we end up with a convention going forward?

[Xinqiu Yao]

Not sure about that. We may think about changing pca.project(), pca.z2xyz(), etc. if CRAN really rejects us because of these.

We may also think of creating a new branch to do name changing for future releases.

For new function, I still suggest that we always start with a short but meaningful name consisting of only alphabets and numbers (without dots or underscores). The name should indicate the ACTION of the function. What do you think?

[Xinqiu Yao]

Have changed names of PCA related functions. Remaining name changes are moved to Todo list.