On Thu, Feb 25, 2010 at 9:23 PM, Peter Danenberg <p...@roxygen.org> wrote: >> > I think you are looking for a different object model than proto >> > offers. There aren't many languages that offer the prototype object >> > model. >> >> Yes, your probably right---I don't have much experience using the >> prototype model. This is the way I expected it to work: >> >> > z <- 1 >> > p <- proto(expr={a <- z}) >> > p$a >> [1] 1 >> > p$z >> Error in get(x, env = this, inherits = inh) : variable "z" was not found > > Which is exactly how it should work! Namespace pollution is orthogonal > to the specific object model, and Duncan's assertion about the > prevalence of prototypes is a red herring. > > Here's how it works in Scheme, for instance, using Neil van Dyke's > Prototype-Delegation package:[1] > > #;1> (use protobj) > #;2> (define z 1) > #;3> (define a (%)) > #;4> (! a a z) > #;5> (? a a) > 1 > #;6> (? a z) > > Error: Object has no such slot: > #<object> > z > > Just like one would expect! And since protobj is based on self, > Ungar-Smith's original prototype system,[2] I suspect that self > behaves similarly. > > Footnotes: > [1] http://www.neilvandyke.org/protobj/ > > [2] http://research.sun.com/self/papers/self-power.html
One would not expect the behavior you cite if you were working in R, only if you were more familiar with something else. One can just as easily argue that consistency and flexibility are more important principles. Your preference is inconsistent with how the rest of R works and is inflexible since everything inherits from Object. In contrast proto uses R-like behavior as its default but is flexible enough that your preference can be accommodated and done so compactly. Also I think your argument is based partly on repeating the original erroneous (relative to the writer's intention) proto code without repeating my correction confusing the discussion with simple user error. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel