On Mar 22, 2013, at 05:57 , Hervé Pagès wrote: > Hi, > > Maybe a compromise would be to just issue a warning without > deprecating? That way people who want to do anova(fit1)$P can > still do it. When working interactively, it's certainly convenient > (serious code however should probably stay away from partial matching).
That's what it does. Issuing a warning when users do X is pretty much equivalent to deprecating X. > > And so you keep the semantic consistent with lists because yes, > consistency is important. data.frame inherits from list so any > operation that works on a list is expected to work on a data.frame, > preferably the same way (otherwise it will always be a BIG surprise > to the user/programmer). For example if I have to maintain someone > else code and see something like: > > bar <- x$bar > > and I know that 'x' is a list that contains atomic vectors of the > same length, I could have some good reasons to want to use a > data.frame instead of a list. And I would assume it's safe to > modify the code by adding the following line earlier in it: > > x <- as.data.frame(x) > > But with the proposed change to $.data.frame, I cannot make this > kind of assumption anymore... No, but it's only a real problem if the component is not actually called "bar". You could make the same point for environments, but they never allowed partial matching: > e <- as.environment(list(barbaric=666)) > e$bar NULL > e$barbaric [1] 666 -- Peter Dalgaard, Professor Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd....@cbs.dk Priv: pda...@gmail.com ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
