On 12/31/2005 4:09 PM, Gabor Grothendieck wrote: > On 12/31/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >>On 12/31/2005 3:26 PM, Gabor Grothendieck wrote: >> >>>I think this is just playng with words. >> >>I'm starting to be convinced of that by the fact that you haven't posted >>any sample code where using a single parameter would be desirable. > > > Loose coupling is a general principle that should be followed as a matter > of course and does not need case by case justification. If there were > a performance issue, say, one might justify circumventing > otherwise desirable principles but there is no conflicting tradeoff here.
Generally I agree, but I've just committed the doc change only, for these reasons: - xy.coords is likely to be used by high-level plot functions that have inputs like plot.default; if they follow its pattern closely, then they'll never need a one-parameter call. This will encourage consistency. - the interface to those functions has been unchanged for years, and I don't like changing old interfaces without strong reasons. This was really a borderline case, but the fact that I couldn't think of a situation where it would be good to use a one parameter call to xy.coords tipped the balance in my mind. Duncan Murdoch > > > >>The fact that its always been >> >>>like that is not sufficient and is not related to consistency. >>>xyz.coords also does not work in accordance with the help file >>>so the fact that the error extends to it just means they are both >>>in error. >> >>>Modularity means loose coupling -- i.e. a function should be >>>as independent as possible from its surroundings. The fact >>>that the second argument is not missing in uses within R base >>>is not a valid argument for appropriate attention to this principle. >>> >>>Furthermore, its clear that the current way it works is not even >>>the intended way -- the intended and better way is as documented >>>and the software, not the documentation, ought to be changed. >> >>Take a look at the examples. It's pretty clear that it is working as >>intended, and the documentation incorrectly says "missing" where it >>means "NULL". >> >>Duncan Murdoch >> >>> >>>On 12/31/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >>> >>> >>>>On 12/31/2005 12:57 PM, Gabor Grothendieck wrote: >>>> >>>> >>>>>It does not achieve design consistency. >>>> >>>>It's consistent with the way it has been for at least 7 years, and is >>>>consistent with xyz.coords(). >>>> >>>>One would have to >>>> >>>> >>>>>specify NULL but that should not really be necessary. >>>> >>>>In fact, one almost never needs to specify NULL there. It's the default >>>>value for y in the high level functions that call xy.coords, so it is >>>>put there automatically. >>>> >>>>Duncan Murdoch >>>> >>>> >>>> >>>>>On 12/31/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>> >>>>>>On 12/31/2005 12:21 PM, Gabor Grothendieck wrote: >>>>>> >>>>>> >>>>>> >>>>>>>I think the point is that (1) it does not work as documented and (2) in >>>>>>>most functions one can omit unnecessary args without having >>>>>>>to specify NULL so its behvaior seems inconsistent from a design >>>>>>>viewpoint. By allowing either missing or NULL it will work as >>>>>>>documented, >>>>>>>and probably intended, yet continue to be backward compatible with >>>>>>>existing usages. >>>>>> >>>>>>But a simpler change is to change the documentation, and it achieves all >>>>>>of those objectives. >>>>>> >>>>>>Duncan Murdoch >>>>>> >>>>>> >>>>>> >>>>>>>On 12/31/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>On 12/31/2005 8:57 AM, Gabor Grothendieck wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>It could be changed to missing(y) || is.null(y) and the docs amended. >>>>>>>>>That way existing code will continue to work and code that otherwise >>>>>>>>>gives an error currently, but should have worked, will now work too. >>>>>>>> >>>>>>>>Can you give an example where you would want to use xy.coords(y ~ x)? >>>>>>>>Normally xy.coords() is used in other functions, and they can default y >>>>>>>>to NULL (see plot.default, for example). >>>>>>>> >>>>>>>>Duncan Murdoch >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>On 12/31/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>On 12/30/2005 10:10 PM, Gabor Grothendieck wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>In ?xy.coords it says: >>>>>>>>>>> >>>>>>>>>>> If 'y' is missing and 'x' is a >>>>>>>>>>> >>>>>>>>>>> formula: of the form 'yvar ~ xvar'. 'xvar' and 'yvar' are used as >>>>>>>>>>> x and y variables. >>>>>>>>>>> >>>>>>>>>>> list: containing components 'x' and 'y', these are used to define >>>>>>>>>>> plotting coordinates. >>>>>>>>>>> >>>>>>>>>>> time series: the x values are taken to be 'time(x)' and the y >>>>>>>>>>> values to be the time series. >>>>>>>>>>> >>>>>>>>>>> matrix with two columns: the first is assumed to contain the x >>>>>>>>>>> values and the second the y values. >>>>>>>>>>> >>>>>>>>>>>however, in fact, if y is missing an error is given. e.g. >>>>>>>>>>> >>>>>>>>>>>x <- 1:3 >>>>>>>>>>>y <- 4:6 >>>>>>>>>>>xy.coords(y ~ x) # error >>>>>>>>>>>xy.coords(cbind(x, y)) # error >>>>>>>>>>>xy.coords(ts(y)) # error >>>>>>>>>>> >>>>>>>>>>>Looking at the code, is.null(y) in the first line of the >>>>>>>>>>>body should be missing(y) . >>>>>>>>>> >>>>>>>>>>It would be better to change the docs to say "if 'y' is NULL ...". >>>>>>>>>>The >>>>>>>>>>code has been the way it is for years and years, and is widely used. >>>>>>>>>> >>>>>>>>>>Changing the test to missing(y) would mean all existing uses that put >>>>>>>>>>a >>>>>>>>>>NULL there would need to be changed. >>>>>>>>>> >>>>>>>>>>Adding a default value of NULL to y would have less impact, but I'd >>>>>>>>>>still be worried about it having long-range bad effects. >>>>>>>>>> >>>>>>>>>>Duncan Murdoch >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>______________________________________________ >>>>>R-devel@r-project.org mailing list >>>>>https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>>> >>>______________________________________________ >>>R-devel@r-project.org mailing list >>>https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel