R help - Mar 2011 - Does R have a "const object"?

Hi, all,

Does R have a "const object" concept like which is in C++ language? I
want to set some data frames as constant to avoid being modified
unintentionally. Thanks!




xiagao1982
2011-03-15

	[[alternative HTML version deleted]]

On 15.03.2011 15:53, xiagao1982 wrote:
> Hi, all,
>
> Does R have a "const object" concept like which is in C++
language? I want to set some data frames as constant to avoid being modified
unintentionally. Thanks!

Although there is almost never a "No" in R, the best short answer is:
"No".

Best,
Uwe  Ligges

>
>
>
> xiagao1982
> 2011-03-15
>
> 	[[alternative HTML version deleted]]
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

On 15/03/2011 2:23 PM, Uwe Ligges wrote:
>
> On 15.03.2011 15:53, xiagao1982 wrote:
> >  Hi, all,
> >
> >  Does R have a "const object" concept like which is in C++
language? I want to set some data frames as constant to avoid being modified
unintentionally. Thanks!
>
>
> Although there is almost never a "No" in R, the best short answer
is: "No".
Very nice answer!  Achim, this is a fortune candidate if I ever saw one!

Duncan Murdoch

On Tue, Mar 15, 2011 at 10:53 AM, xiagao1982 <xiagao1982 at gmail.com>
wrote:
> Hi, all,
>
> Does R have a "const object" concept like which is in C++
language? I want to set some data frames as constant to avoid being modified
unintentionally. Thanks!
>
>
LockBinding will prevent a variable from being modified (but you could
still rm it and then subsequently create a variable of the same name).
> xx <- 33
> lockBinding("xx", .GlobalEnv)
> xx <- 44
Error: cannot change value of locked binding for
'xx'
> rm(xx) # can still do this

-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

On Wed, 16 Mar 2011, Gabor Grothendieck wrote:
> On Wed, Mar 16, 2011 at 11:49 AM,  <luke-tierney at uiowa.edu> wrote:
>> Just as a heads-up: it is likely that unlocking the bindings in base
>> for pi, T, F, probably all BULTIN and SPECIAL functions, and possibly
>> more, will start signaling warnings in the near future. ?Doing this
>> may be useful at times for debugging but it can mess up assumptions
>> others make about how things in base work and so reduce code
>> reliability.
>
> That seems ok for pi, T and F but if its extended to everything in
> base then I would hope there is a nowarn= argument or other easy way
> to avoid the warning message.
>
That would defeat the purpose.  Unlocking things in base may be useful
for experimenting or debugging but it is not a good idea otherwise.
[? assignInNamespace could be more explicit on htis and will be soon.]
There is a reason we lock bindings in the first place, and that is so
one can assume that these bindings have certain values and certain
properties and one can write reliable programs against these
assumptions.

Best,

luke

-- 
Luke Tierney
Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu

On Wed, Mar 16, 2011 at 12:16 PM,  <luke-tierney at uiowa.edu>
wrote:
> On Wed, 16 Mar 2011, Gabor Grothendieck wrote:
>
>> On Wed, Mar 16, 2011 at 11:49 AM, ?<luke-tierney at uiowa.edu>
wrote:
>>>
>>> Just as a heads-up: it is likely that unlocking the bindings in
base
>>> for pi, T, F, probably all BULTIN and SPECIAL functions, and
possibly
>>> more, will start signaling warnings in the near future. ?Doing this
>>> may be useful at times for debugging but it can mess up assumptions
>>> others make about how things in base work and so reduce code
>>> reliability.
>>
>> That seems ok for pi, T and F but if its extended to everything in
>> base then I would hope there is a nowarn= argument or other easy way
>> to avoid the warning message.
>>
>
> That would defeat the purpose. ?Unlocking things in base may be useful
> for experimenting or debugging but it is not a good idea otherwise.
> [? assignInNamespace could be more explicit on htis and will be soon.]
> There is a reason we lock bindings in the first place, and that is so
> one can assume that these bindings have certain values and certain
> properties and one can write reliable programs against these
> assumptions.
>
Its useful for being able to set defaults for arguments that do not
have defaults.  That cannot break existing programs.

Note that if this feature is implemented in a heavy handed manner it
could cause havoc as at least one package that is depended upon by
literally dozens of other packages (and possibly hundreds if one takes
into account dependencies of dependencies) cannot function.

-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com