[S] Is this really good programming practice?

Brett Presnell (presnell@maths.anu.edu.au)
Fri, 27 Mar 1998 19:50:34 +1100

Once again I find myself needing to write a modeling function along
the lines of lm, glm, gam, etc., and this time I thought I would try
to understand the finer points of some of the things that I might copy
from these "prototypes".

Here's something that is currently bothering me. In the argument list
to glm and gam one finds "start=eta". It seems reasonable to ask how
this works, given that I can run glm without having any eta defined
anywhere, and moreover, even if I do have an eta defined it is
ignored. This is explained by the fact that "start" is only accessed
indirectly through the value of "match.call(expand=F)" which doesn't
have "start" in it if the user doesn't specify start in the call.

Isn't this a pretty strange thing to do? Wouldn't it be perfectly
reasonable for a user who looks at the output of "args(glm)" to think
that simply creating a vector "eta" would suffice to pass starting
values to the function. Why not have "start=NULL" as the default?
When I first started looking at this I thought I saw some reason for
doing things this way as a matter of convenience, but at the moment I
don't see any reason at all.

Even with "start=NULL" the current code would still rely on the fact
that start is only accessed through match.call, since an error results
if we actually specify "start=NULL" in the call. This seems like
sloppy programming practice, especially since it again would seem to
be perfectly reasonable to specify "start=NULL" when calling glm. Why
not have "start=NULL" as the default, and then a line like

if (is.null(start)) m$start <- NULL

before "eval(m,sys.parent())"?

Ok, now someone can tell me how it is that I'm missing the point
entirely. :-}

Brett Presnell
This message was distributed by s-news@wubios.wustl.edu. To unsubscribe
send e-mail to s-news-request@wubios.wustl.edu with the BODY of the
message: unsubscribe s-news