From murdoch at stats.uwo.ca  Fri Nov 13 20:47:38 2009
From: murdoch at stats.uwo.ca (Duncan Murdoch)
Date: Fri, 13 Nov 2009 14:47:38 -0500
Subject: [Rd] The default behaviour of a missing entry in an environment
In-Reply-To: <39831344-CF89-4D0C-9804-702B80D4DE4C@nyu.edu>
References: <D737F65B-A317-44C1-8421-E8DE2D0E0740@nyu.edu>	<4AFDB33D.5010607@stats.uwo.ca>
	<39831344-CF89-4D0C-9804-702B80D4DE4C@nyu.edu>
Message-ID: <4AFDB7DA.3080104@stats.uwo.ca>

On 11/13/2009 2:39 PM, Trishank Karthik Kuppusamy wrote:
> Hello Duncan,
> 
> Thanks for your reply.
> 
> On Nov 13, 2009, at 2:27 PM, Duncan Murdoch wrote:
> 
>> You get the same behaviour when asking for a nonexistent element of a list, or a nonexistent attribute.   If you want stricter checking, don't use $, use get():
>> 
>> > get("b", e)
>> Error in get("b", e) : object 'b' not found
> 
> Yes, this is a solution. However, if we agree that "$" is (as it should be) syntactic sugar for get(), then why do we have different behaviour
> for what should essentially be the same operations, albeit the former being easier to read and write than the latter?
> Or is my premise mistaken and that is the whole point of having "$" and get() which are not identical?
> 
>> But then it would be inconsistent with what it does in other situations.
> 
> I am afraid that I did not fully understand this point. What would the inconsistencies be in other situations?

Inconsistent with what happens for lists:

 > x <- list()
 > x$b
NULL

and attributes:

 > attr(x, "b")
NULL

It is already a little stricter than $ on a list:

 > x$longname <- 1
 > x$long
[1] 1
 > e$longname <- 1
 > e$long
NULL

so I supposed we could make it even more strict, but there is an awful 
lot of code out there that uses tests like

if (!is.null(x <- e$b)) { do something with x }

and all of that would break.

Duncan Murdoch



[Rd] The default behaviour of a missing entry in an environment
Duncan Murdoch