R devel - Feb 2013 - Private environments and/or assignInMyNamespace

Dear DevelopeRs,

I've been struggling with the new regulations regarding modifications to 
the search path, regarding my Rcmdr plugin package RcmdrPlugin.DoE. John 
Fox made Rcmdr comply with the new policy by removing the environment 
RcmdrEnv from the search path. For the time being, he developed an 
option that allows users to put the environment from Rcmdr (RcmdrEnv) on 
the search path, like in earlier versions of Rcmdr (thanks John!), which 
rescues my package for the immediate future; however, in the long run it 
would be nice to be able to make it work without that.

The reason why I currently need the environment on the search path (may 
be due to my lack of understanding how tcltk widgets are handled): I 
have quite elaborate notebook widgets on which users can make many 
entries. Some entries are only checked after clicking OK, and if an 
error is found at that point, the user receives a small message window 
that has to be confirmed and is subsequently returned to the notebook 
widget in the state it was in when pressing OK. These widgets are 
currently held in the environment RcmdrEnv; they work when RcmdrEnv is 
on the search path; however, it is not sufficient to retrieve them with 
John's function getRcmdr, which works fine for objects other than widgets.

Here my question: Would it be an option to place the widgets in a 
private environment of my plugin package (then I would have to learn how 
to create one and work with it), or won't they be found that way? 
Alternatively, I could have unexported objects of all required names in 
my namespace and modify these via assignInMyNamespace (I don't think 
that anybody from somewhere else would import that namespace, it's not 
that kind of package). Would that be a viable alternative, and would the 
widgets be found that way? Any further ideas?

Best regards,
Ulrike

-- 
*****************************************************
* Ulrike Groemping                                  *
* BHT Berlin - University of Applied Sciences       *
*****************************************************
* +49 (30) 39404863 (Home Office)                   *
* +49 (30) 4504 5127 (BHT)                          *
*****************************************************
* http://prof.beuth-hochschule.de/groemping         *
* groemping at bht-berlin.de                           *

> Here my question: Would it be an option to place the widgets in a private
> environment of my plugin package (then I would have to learn how to create
> one and work with it), or won't they be found that way?
It sounds like you want to maintain state across function calls within
your package, and a private environment is a good solution.  See the
notes on local() at
https://github.com/hadley/devtools/wiki/Environments for a few
details.

Hadley

-- 
Chief Scientist, RStudio
http://had.co.nz/

Le mardi 12 f?vrier 2013 ? 14:45 +0100, Ulrike Gr?mping a ?crit
:
> Dear DevelopeRs,
> 
> I've been struggling with the new regulations regarding modifications
to
> the search path, regarding my Rcmdr plugin package RcmdrPlugin.DoE. John 
> Fox made Rcmdr comply with the new policy by removing the environment 
> RcmdrEnv from the search path. For the time being, he developed an 
> option that allows users to put the environment from Rcmdr (RcmdrEnv) on 
> the search path, like in earlier versions of Rcmdr (thanks John!), which 
> rescues my package for the immediate future; however, in the long run it 
> would be nice to be able to make it work without that.
> 
> The reason why I currently need the environment on the search path (may 
> be due to my lack of understanding how tcltk widgets are handled): I 
> have quite elaborate notebook widgets on which users can make many 
> entries. Some entries are only checked after clicking OK, and if an 
> error is found at that point, the user receives a small message window 
> that has to be confirmed and is subsequently returned to the notebook 
> widget in the state it was in when pressing OK. These widgets are 
> currently held in the environment RcmdrEnv; they work when RcmdrEnv is 
> on the search path; however, it is not sufficient to retrieve them with 
> John's function getRcmdr, which works fine for objects other than
widgets.
I'm not sure I understand exactly how this works, but does that mean you
close the dialog before checking the entries? If it is the case, you
could check them before, and if an error is detected, you would keep the
dialog open: this way, you would not need to restore anything.

Could you point us at the relevant code?


Regards
> Here my question: Would it be an option to place the widgets in a 
> private environment of my plugin package (then I would have to learn how 
> to create one and work with it), or won't they be found that way? 
> Alternatively, I could have unexported objects of all required names in 
> my namespace and modify these via assignInMyNamespace (I don't think 
> that anybody from somewhere else would import that namespace, it's not 
> that kind of package). Would that be a viable alternative, and would the 
> widgets be found that way? Any further ideas?
> 
> Best regards,
> Ulrike
>