Change the default symbol name to something other than D so that users get more helpful error messages

[tombisho]

The default symbol name when assigning data in a new DataSHIELD session is "D".

If something goes wrong during assignment, the log in still occurs. Although the user gets an error they might not notice. They then try and do an operation like ds.asNumeric("D$cens", "CENS.num") but receive the error:

Error in D$cens : object of type 'closure' is not subsettable\n"

This causes confusion, and it happens because there is a function D().

Perhaps we should consider a different default name? Definitely not T or F. Maybe R? or DS?

I appreciate this produces a lot of work in documentation where "D" is hardcoded in already, so we might not want to do it.

[StuartWheater]

This is something I have wondered about.
If this changes is made it could cause some analysis scripts to stop working, but simply adding 'symbol="D"' during login setup would fix that.

[ymarcon]

Yep, changing defaults is not "backward compatible". Personally I think that DS team should promote to assign tables/resources after the login (using datashield.assign.*) as a best-practice. If assign fails in datashield.login you never know if you are logged in or not.

[tombisho]

Ok so maybe the proposed change would be to improve the help, wiki etc to advise using a separate assign statement, and to not use "D". I agree that it would be good to retain backward compatibility. Eventually this would result in a move away from the use of "D" and the problem would be a much more rare occurence.

Maybe this then belongs in dsBaseClient?

[StuartWheater]

We talked about this in the morning meeting. Alex is looking at reworking the tutorials not to use "D", and use "datashield.assign.*".

[tombisho]

Great - sorry I wasn't there, strictly I am on holiday!

I don't have permission to move this issue to dsBaseClient, so please could someone else move it?