[R-sig-Geo] Combining polygons and calculating their area (i.e. number of cells)

[Roger Bivand]

On Thu, 19 Dec 2013, Josh O'Brien wrote:

> On Thu, Dec 19, 2013 at 4:23 AM, Roger Bivand <Roger.Bivand at nhh.no> wrote:
>
>> On Wed, 18 Dec 2013, Josh O'Brien wrote:
>>
>
> <...snip...>
>
> By the way, always avoid accessing S4 objects directly using @, do use
>> slot(obj, "slotname") - the sapply should read:
>>
>> area = sapply(slot(SPclus, "polygons"), slot, "area")
>>
>> for the SO version with possibly incorrect areas, and
>>
>> area = gArea(SPclus, byid=TRUE)
>>
>> for correct ones.
>
>
> Would you mind explaining why the functional form, slot(obj, "slotname"),
> should always be used instead of obj at slotname ? I've seen this admonition
> repeatedly -- I think just from you -- and don't know whether it's a purely
> stylistic preference on your part, or whether there  is some other
> rationale for preferring that form.

When sp was written (2003-5), we chose to use S4 (new style) classes. We 
used Chambers (1998), referring to Ch. 7, and on slots pp. 290-292. There 
the distinction between S3 (old style) "$" and "$<-" access and 
replacement methods, and S4 "@" and particularly "@<-" was made more 
forcefully than in Chambers (2008). Contemporary uses described in 
Venables and Ripley (2000) also distinguish between the two.

All of these point to the formal use of S4 class definitions, not least to 
ensure that storage mode checking when using .C() and .Call() cease to be 
so time-consuming. This is an issue with S3 classes, because there is 
nothing to stop the user modifying the storage mode of list components, 
with potentially bad consequences in compiled code. Defensive changes in 
the underlying R engine to detect mode mismatch were introduced very much 
later, I believe, so mode mismatch could crash the engine until them.

For both S3 and S4 classes, the user is encouraged to use access functions 
where provided. If the classes and methods are sufficiently well written, 
there should only be a few occasions in which the user might want to 
access components (S3) or slots (S4) that are not exposed via methods. If 
scripts consistently contain @, and no access or replacement methods are 
provided, consider asking the package maintainer to add the missing 
functionality. slot() is a little less ugly, but the user shouldn't really 
need it either, unless something inside an object has to be shown or 
manipulated.

In this case, the "area" slot is documented, but precisely because it is 
not intended to be used as a measure of area, there is no access method.

The danger is that "@<-" and "$<-" are used to insert values into 
components/slots without sufficient care being taken; access is perhaps 
less of a problem.

I particularly react to usages such as:

sdf at data$var

for sdf a Spatial*DataFrame object, as "$" and "$<-" methods *are* 
provided to let these objects appear to be data.frame objects. This usage 
is redundant, and displays ignorance about the class/method systems in S 
and R. Of course, all are free to write what they like, so my preferences 
may be just a matter of taste, but at least they are based on the books 
written to establish the structure of the language.

Hope this clarifies,

Roger

>
> FWIW, the ?slot help page doesn't include any such direction, only noting
> in its documentation of the name argument that:
>
>          In the case of the ‘slot’ function, ‘name’ can be any
>          expression that evaluates to a valid slot in the class
>          definition.  Generally, the only reason to use the functional
>          form rather than the simpler operator is _because_ the slot
>          name has to be computed.
>
> Is there some other reason to prefer the functional form?
>
> Josh
>
>
>> Finally, never use T/F for TRUE and FALSE, try:
>>
>> T <- FALSE
>>
>> and TRUE <- FALSE
>>
>> and see the difference.
>>
>> Terminally uninterested in winning points on SO,
>>
>> Roger
>>
>>
>>>
>>> --
>>> View this message in context: http://r-sig-geo.2731867.n2.
>>> nabble.com/Combining-polygons-and-calculating-their-area-i-
>>> e-number-of-cells-tp7585395p7585401.html
>>> Sent from the R-sig-geo mailing list archive at Nabble.com.
>>>
>>> _______________________________________________
>>> R-sig-Geo mailing list
>>> R-sig-Geo at r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>>
>> --
>> Roger Bivand
>> Department of Economics, Norwegian School of Economics,
>> Helleveien 30, N-5045 Bergen, Norway.
>> voice: +47 55 95 93 55; fax +47 55 95 95 43
>> e-mail: Roger.Bivand at nhh.no
>>
>>
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no