Re: Ming Tan's dilemma on variables in functions.

Duncan Murdoch (dmurdoch@mast.QueensU.CA)
Sat, 23 Jul 1994 08:41:28 -0400 (EDT)


> Obligatory paternalistic advice:
>
> Whether the local frame of the function should be on the search list or not
> is a topic of some debate, but the fact is it is *not* and to change this
> would break so many things in S it seems unlikely to happen. Rather than
> wait for that day which may never come, it seems better for now to embrace
> the object oriented style of programming more fully. Work with variables
> in *data frames* and always use the data= argument of the fitting function
> to make them part of the fitted model object. In this way the variables go
> wherever the object goes and the problem simply does not arise.

I don't see what data frames have to do with this. In order to get your
data.frame solution to work, the data.frame had to be made global.
The problem here is how scoping works, and what gets stored in the
result of a call to a fitting function.

One solution that would work without putting the function's locals on
the search list is to introduce the idea of pointers to S. The result
of a fit wouldn't just contain the names of the variables involved, it
would also contain pointers to the actual instances that were involved
in the fit. I don't know if this would break more code or less than
modifying the search list, but I'd suspect less. It must be fairly
unusual to slip new data into the search list ahead of the original data
used for a fit, and if you didn't do that, you should get identical
results. But maybe introducing pointers would break other things.

Duncan Murdoch