{"action":"reopened","issue":{"url":"https://api.github.com/repos/dankelley/oce/issues/965","repository_url":"https://api.github.com/repos/dankelley/oce","labels_url":"https://api.github.com/repos/dankelley/oce/issues/965/labels{/name}","comments_url":"https://api.github.com/repos/dankelley/oce/issues/965/comments","events_url":"https://api.github.com/repos/dankelley/oce/issues/965/events","html_url":"https://github.com/dankelley/oce/issues/965","id":153648764,"number":965,"title":"should read.ctd.sbe() make up e.g. the 'salinity' entry?","user":{"login":"dankelley","id":99469,"avatar_url":"https://avatars.githubusercontent.com/u/99469?v=3","gravatar_id":"","url":"https://api.github.com/users/dankelley","html_url":"https://github.com/dankelley","followers_url":"https://api.github.com/users/dankelley/followers","following_url":"https://api.github.com/users/dankelley/following{/other_user}","gists_url":"https://api.github.com/users/dankelley/gists{/gist_id}","starred_url":"https://api.github.com/users/dankelley/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dankelley/subscriptions","organizations_url":"https://api.github.com/users/dankelley/orgs","repos_url":"https://api.github.com/users/dankelley/repos","events_url":"https://api.github.com/users/dankelley/events{/privacy}","received_events_url":"https://api.github.com/users/dankelley/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/dankelley/oce/labels/ctd","name":"ctd","color":"5319e7"},{"url":"https://api.github.com/repos/dankelley/oce/labels/Development","name":"Development","color":"bfd4f2"}],"state":"open","locked":false,"assignee":{"login":"dankelley","id":99469,"avatar_url":"https://avatars.githubusercontent.com/u/99469?v=3","gravatar_id":"","url":"https://api.github.com/users/dankelley","html_url":"https://github.com/dankelley","followers_url":"https://api.github.com/users/dankelley/followers","following_url":"https://api.github.com/users/dankelley/following{/other_user}","gists_url":"https://api.github.com/users/dankelley/gists{/gist_id}","starred_url":"https://api.github.com/users/dankelley/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dankelley/subscriptions","organizations_url":"https://api.github.com/users/dankelley/orgs","repos_url":"https://api.github.com/users/dankelley/repos","events_url":"https://api.github.com/users/dankelley/events{/privacy}","received_events_url":"https://api.github.com/users/dankelley/received_events","type":"User","site_admin":false},"milestone":null,"comments":10,"created_at":"2016-05-08T10:45:11Z","updated_at":"2016-05-13T03:40:51Z","closed_at":null,"body":"Now that I am making `[[` work better, and making ``lookWithin` better, so that the `sw*` functions can create fake columns 'on the fly', I am starting to think there is not much real reason to create a `salinity` entry, or a `pressure` entry.  I am not totally sure either way, though, which is why I'm hoping @richardsc can give this a think and comment. Here is my list of pros and cons.\r\n\r\n**Arguments to keep creating salinity etc**\r\n\r\n1. We've done that in the past so we don't have to worry about code ripples if we stop. These relate to hard-wired accesses  e.g. `x@data$salinity`. There is no problem if we use `x[[\"salinity\"]]` which can construct the data on the fly. With `git grep \"@data\\$salinity\"|wc` I get 51 such cases.\r\n\r\n2. Generally, I think it's a poor idea to make tricky changes a week before a cran submission.\r\n\r\n**Arguments to stop creating salinity etc**\r\n\r\n1. A general theme of oce over the past year or so has been to try to store data in a form that is close to that of the original data. (For example, landsat stores 1- and 2-byte entries; adp stores 1-byte entries, etc.)\r\n\r\n2. Regarding \"against\" item 1, those 51 cases are not a true problem for coding. Also, we have for a long time told users to use `[[\"X\"]]` instead of `@data$X` so we may be ok on user code.  (I'm not sure how often you use the `@data` method, though, Clark.)\r\n\r\n3. With the new handling of short-names, users will be a lot closer to their data, and we should let them choose how to calculate salinity etc.  (Example: there might be multiple C sensors.)\r\n\r\n4. I suspect that most datasets already have e.g. salinity and pressure, and that people working with datasets that lack those thing already know what they are doing. This sort of relates to the previous point, actually ... auto-constructing a fake column might not be helpful to these users.\r\n\r\nEven after writing the list (a strategy I use to try to make up my mind) I am still a bit divided. Regarding \"against point 1\", I would say that I should be cleaning that code anyhow. Regarding \"against point 2\", I do think that is valid, and important. That means that, for me, the issue really comes down to a question of timidity.\r\n\r\nThoughts, Clark?"}}