On 26/02/2010 7:09 AM, Gabor Grothendieck wrote:
On Fri, Feb 26, 2010 at 12:41 AM, Peter Danenberg <p...@roxygen.org> wrote:
Also other object systems which are alternatives to proto seem less
relevant than basic scoping and free variable lookup in functions.
Sorry, but that seems absurd; object systems are less relevant to each
other than the totally orthogonal question of scope?
Yes, if you are using one then obviously you have decided to use it in
place of the other. Also your example of S3 was misleading since it
used lists which do not have inheritance and did not truly illustrate
S3. Free variables in S3 methods follow the same lookup procedure as
ordinary functions and using S3 together with proto works well. In
fact, proto uses two S3 classes.
proto does that but uses the consistent default rather than the
inconsistent default that you prefer.
$.proto falls back upon get(), I presume, because the authors didn't
feel like recursing up the parent hierarchy themselves; I'll continue
to believe that the scope pollution was an oversight until they
contradict me. At which point I'll probably switch object systems.
Here I think you are admitting that the basic facilities of R do work
in the way proto does.
Also, your alternative likely would be unusable due to performance
whereas proto is fast enough to be usable (see list of applications
that use it at http://r-proto.googlecode.com/#Applications). Its not
as fast as S3 (though sometimes you can get it that fast by optimizing
your code). The development version of proto is even faster than the
current version of proto due to the addition of lazy evaluation.
Vague appeals to consistency, when you're really only talking about
naive get() semantics, don't mean much; especially after you've spent
hours debugging mysterious bugs resulting from scope pollution.
In end it seems that your real beef is with R so perhaps you should be
using a different language.
With respect to proto its really just discussing whether to use
proto(baseenv(), ...) vs proto(...)
I would say the default behaviour makes more sense. There are very few
circumstances in R where scoping makes locals and base variables
visible, *but nothing else*. I think users would be surprised that
a$ls()
works, but
a$str()
fails (because str() is in utils, ls() is in base). Effectively what
the current default says is that objects inherit from the current
environment. That's how environments work in R.
One thing that I dislike about scoping in R is the fact that even in a
namespace, searches eventually get to the global environment. I'd
prefer if namespace searches went through the imported namespaces and
nothing else. If that were the case, then the a$z example would never
find a z in the global environment, and that example would only be a
problem for people fiddling around in the console, not programming
carefully in a package. But again, this is a criticism of R, not of
proto. (I believe the reason for the current behaviour is to support
finding S3 methods: a user should be able to define a new class and an
S3 method for it, and R should find it even if the writer of the
original generic knew nothing about the new class or method. This
outside-the-namespace search is needed for that, but I'd prefer it if it
were more limited.)
Duncan Murdoch
since the former gives you everything you want and the distinction
seems pretty trivial given how easy it is to use one or the other. If
you used iolanguage or similar you would have to specify Object so
there is not even a penalty in terms of compactness.
There have also been threads on how to "fix" scoping in R for
individual functions and various manipulations of environments have
been suggested but in the end no one does this in practice. In proto
at least you can do the part you want and its trivial to do so.
______________________________________________
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
