> 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
Added one other comment below.
On Fri, Feb 26, 2010 at 9:41 PM, Gabor Grothendieck
wrote:
> On Fri, Feb 26, 2010 at 8:46 PM, Ben wrote:
>> Maybe I'm still not getting something fundamental, but I didn't intend
>
> I think you are missing the R search path. Try this:
>
> search()
>
> That shows
On Fri, Feb 26, 2010 at 8:46 PM, Ben wrote:
> Maybe I'm still not getting something fundamental, but I didn't intend
I think you are missing the R search path. Try this:
search()
That shows you the search path. Normally it starts searching at the
beginning and moves forward.
> my "proto(base
Maybe I'm still not getting something fundamental, but I didn't intend
my "proto(baseenv(), expr={a <- z})$a" example to be realistic. In
practice "a <- z" would be replaced with hundreds of lines of code,
where many functions are called. In theory you could track down every
function that's globa
On Fri, Feb 26, 2010 at 9:01 AM, Ben wrote:
>
>> In end it seems that your real beef is with R so perhaps you should
>> be using a different language.
>
> In my case you may be right. I do think there are a million things
> wrong with R. For instance, I was looking for a package that
> overcomes
> In end it seems that your real beef is with R so perhaps you should
> be using a different language.
In my case you may be right. I do think there are a million things
wrong with R. For instance, I was looking for a package that
overcomes two of the problems R IMHO has: namespace pollution an
On 26/02/2010 7:09 AM, Gabor Grothendieck wrote:
On Fri, Feb 26, 2010 at 12:41 AM, Peter Danenberg 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
On Fri, Feb 26, 2010 at 12:41 AM, Peter Danenberg 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
> 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?
> proto does that but uses the con
On Thu, Feb 25, 2010 at 11:16 PM, Peter Danenberg wrote:
>> Your preference is inconsistent with how the rest of R works and is
>> inflexible since everything inherits from Object.
>
> Really? Here are a couple of counterexamples in S3 and S4 objects:
>
> > z <- 1
> >
> > ## S4
> > setClass('A
> Your preference is inconsistent with how the rest of R works and is
> inflexible since everything inherits from Object.
Really? Here are a couple of counterexamples in S3 and S4 objects:
> z <- 1
>
> ## S4
> setClass('A', representation(a='numeric'))
[1] "A"
> a <- new('A', a=z)
>
On Thu, Feb 25, 2010 at 9:23 PM, Peter Danenberg 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 mo
> > 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
> >
On Thu, Feb 25, 2010 at 7:49 PM, Ben 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 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={
> Hey, Hadley; I remember your prototype stuff from DSC 2009. I saw some
> slides of yours that discussed proto, and was wondering whether mutatr
> was still maintained.
Yes, it's maintained, and I've even written a package that uses it
(testthat - both it and mutatr are available on cran). It's
Quoth Gabor Grothendieck on Sweetmorn, the 56th of Chaos:
> I think his objection is really only that he must specify baseenv()
> to get the behavior he prefers but from what I understand (I am
> basing this on my understanding that mutatr works like io language)
> in mutatr one must use Object whi
Quoth hadley wickham on Sweetmorn, the 56th of Chaos:
> You might want to have a look at the mutatr package which implements
> prototype OO with the behaviour you're looking for (I think).
Hey, Hadley; I remember your prototype stuff from DSC 2009. I saw some
slides of yours that discussed proto,
On Thu, Feb 25, 2010 at 9:57 AM, hadley wickham wrote:
>> Presumably if I ask for p$a or p$b later, it's because I'm interesting
>> in the value of "p$a" or "p$b" that I specifically put inside that
>> environment. Otherwise I would just ask for "a" or "b". If I'm
>> asking for "p$b" it the abov
> Presumably if I ask for p$a or p$b later, it's because I'm interesting
> in the value of "p$a" or "p$b" that I specifically put inside that
> environment. Otherwise I would just ask for "a" or "b". If I'm
> asking for "p$b" it the above case, that means I forgot to declare b
> inside p. In thi
On 25/02/2010 8:50 AM, Ben wrote:
I was disappointed in this behavior because it seems error-prone.
Suppose I declare an environment
> b <- 1
> p <- proto(expr={
a <- 2
+ ...
+ })
> p$a
[1] 2
> p$b
[1] 1
Presumably if I ask for p$a or p$b later, it's because I'm interesting
in the value o
I was disappointed in this behavior because it seems error-prone.
Suppose I declare an environment
> b <- 1
> p <- proto(expr={
a <- 2
+ ...
+ })
> p$a
[1] 2
> p$b
[1] 1
Presumably if I ask for p$a or p$b later, it's because I'm interesting
in the value of "p$a" or "p$b" that I specifically
Am 25.02.2010 06:33, wrote Ben:
Wow, thanks for the heads-up. That is horrible behavior. But using
baseenv() doesn't seem like the solution either. I'm new to proto,
but it seems like this is also a big drawback:
z<- 1
proto(baseenv(), expr={a=z})$a
Error in eval(expr, envir, enclos) : obje
That is how R works with free variables, e.g.
z <- 1
f <- function() z
f() # 1
so the current behavior seems consistent with the rest of R.
Note that the example below could be done like this to avoid the error:
> z <- 1
> proto(baseenv(), a = z)$a
[1] 1
On Thu, Feb 25, 2010 at 12:33 AM, Ben
Quoth Ben Escoto on Sweetmorn, the 56th of Chaos:
> I'm new to proto, but it seems like this is also a big drawback:
>
> > z <- 1
> > proto(baseenv(), expr={a=z})$a
> Error in eval(expr, envir, enclos) : object "z" not found
Ouch, good point; it may be that parent pollution is the lesser of two
e
Wow, thanks for the heads-up. That is horrible behavior. But using
baseenv() doesn't seem like the solution either. I'm new to proto,
but it seems like this is also a big drawback:
> z <- 1
> proto(baseenv(), expr={a=z})$a
Error in eval(expr, envir, enclos) : object "z" not found
--
Ben
--
I understand why the following happens ($.proto delegates to get,
which ascends the parent hierarchy up to globalenv()), but I still
find it anti-intuitive:
> z <- 1
> y <- proto(a=2)
> y$z
[1] 1
Although this is well-documented behavior; wouldn't it uphold the
principle of least surprise
27 matches
Mail list logo
