[R] Does R have a "const object"?
ggrothendieck at gmail.com
Wed Mar 16 22:42:27 CET 2011
On Wed, Mar 16, 2011 at 1:12 PM, <luke-tierney at uiowa.edu> wrote:
> On Wed, 16 Mar 2011, Gabor Grothendieck wrote:
>> 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
>>>> 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
>> Its useful for being able to set defaults for arguments that do not
>> have defaults. That cannot break existing programs.
> Until the next program decides do co change those defaults and either
> can't or does and you end up with incompatible assumptions. It also
> make the code with the added defaults inconsistent with the
> documentation though, which is not a good idea. It may seem
> convenient but it isn't a good idea in production code that is
> intended to play well with other production code.
>> 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.
> The reason I sent my initial message is so those who do this sort of
> thing can start thinking about other approaches. I do not expect to
> need this change for closures any time soon, but will need it for
> constants and primitives. It may be useful for some closures as well,
> so that change may come farther down the line.
If the core group is willing to fix certain design errors in R that
make this necessary I would not be so concerned but to not address
them and also remove the facility that lets the user implement a
workaround is really intolerable.
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
email: ggrothendieck at gmail.com
More information about the R-help