Talk:R/Interfacing with GIS

From QERM Wiki
Revision as of 17:04, 1 September 2010 by Ian (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Why can't things just work?

Masterful work, Dr. Gurarie! I wandered around in R-email-list-land to learn more about the inspiration for deprecating the functions that worked so well. Here is my favorite finding:

By the time I get a little grasp on things, they become "deprecated" :-). Mihai Nica in reference to a discussion about 'polylist'

Here's some stuff about slots from Robert Gentleman's (2003) | "S4 Classes in 15 pages, more or less":

Slots can always be accessed directly using the @ operator. This practice is not recommended (for Bioconductor) since it produces code that depends on the actual class representation. Should that representation change, for example some slots dropped in favour of them being computed or renamed for some reason, then all of the code that uses the @ operator must be identified and modified. Instead we recommend using the convention of accessing the slots via methods (while this produces a lot of generic functions the abstraction gained more than offsets this).
Suppose that the class foo has a slot named a. To create an accessor function for this slot you can proceed as shown below.
  > setClass("foo", representation(a = "ANY"))
  [1] "foo"
  > if (!isGeneric("a")) {
  + if (is.function("a"))
  + fun <- a
  + else fun <- function(object) standardGeneric("a")
  + setGeneric("a", fun)
  + }
  [1] "a"
  > setMethod("a", "foo", function(object) object@a)
  [1] "a"
  > b <- new("foo", a = 10)
  > a(b)
  [1] 10

Does any of this make sense to me? NO!

-Ian 10:02, 1 September 2010 (PDT)

a further note, however: my brief experience with GIS software indicated that it is more confusing to deal with that anything you've faced so far
-Ian 10:04, 1 September 2010 (PDT)
Personal tools