[R] Does R have a "const object"?

[Gabor Grothendieck]

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
>>>>> 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.
>
> 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.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com