On Wed, Mar 16, 2011 at 1:12 PM, <luke-tier...@uiowa.edu> wrote: > On Wed, 16 Mar 2011, Gabor Grothendieck wrote: > >> On Wed, Mar 16, 2011 at 12:16 PM, <luke-tier...@uiowa.edu> wrote: >>> >>> On Wed, 16 Mar 2011, Gabor Grothendieck wrote: >>> >>>> On Wed, Mar 16, 2011 at 11:49 AM, <luke-tier...@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 ______________________________________________ R-help@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.
