Re: [Rd] Constructor/extractor.
Hi Rolf, Barry, On 03/04/2014 08:08 AM, Barry Rowlingson wrote: On Tue, Mar 4, 2014 at 1:47 AM, Rolf Turner wrote: Questions: == (2) Even if there are no such functions, is there anything intrinsically *wrong* with having a function possessing this somewhat schizophrenic nature? Is it likely to cause confusion, induce syntactical mistakes, create errors, or produce wrong results? Any thoughts, comments, insights or suggestions gratefully received. I don't see why you can't conceptually think of w = owin(some_ppp_object) as an owin "Constructor" rather than an "Accessor". Its "constructing" (and returning) an owin from an object, it just happens to be as simple as getting a component from that object. The raster package has the 'extent' function - you can create an extent with extent(xmin,xmax,,,etc), get the extent of a raster with extent(r), or set the extent of a raster with extent(r1) <- extent(r2), so I don't see any problem with: w1 = owin(poly=...) # construct polygon owin ppp1 = ppp(x,y,window=w1) ppp2 = ppp(x,y, window=owin(ppp1)) # construct window from ppp object owin(ppp1) = owin(ppp2) # give ppp1 the owin of ppp2 That all reads pretty nicely. As long as owin(...) returns an observation window and owin<-(...) assigns an observation window to an object that can validly have one, I don't think you can go wrong. I've probably already tried to do "owin(ppp1)=..." a few times... I agree with Barry. Once you realize there is no clear line between constructor and extractor (conceptually every function can actually be thought of as a constructor), then re-using the same function name (via methods of a generic function) doesn't sound too bad. An example of this design is the strand() generic in Bioconductor: can be used to get or set the strand factor of an object containing such a component (e.g. a GRanges object), and also for constructing a strand factor from different kinds of input (character, logical, integer vector, etc...) Cheers, H. Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Constructor/extractor.
On Tue, Mar 4, 2014 at 1:47 AM, Rolf Turner wrote: > > > Questions: > == > > > (2) Even if there are no such functions, is there anything intrinsically > *wrong* with having a function possessing this somewhat schizophrenic > nature? Is it likely to cause confusion, induce syntactical mistakes, > create errors, or produce wrong results? > > Any thoughts, comments, insights or suggestions gratefully received. > I don't see why you can't conceptually think of w = owin(some_ppp_object) as an owin "Constructor" rather than an "Accessor". Its "constructing" (and returning) an owin from an object, it just happens to be as simple as getting a component from that object. The raster package has the 'extent' function - you can create an extent with extent(xmin,xmax,,,etc), get the extent of a raster with extent(r), or set the extent of a raster with extent(r1) <- extent(r2), so I don't see any problem with: w1 = owin(poly=...) # construct polygon owin ppp1 = ppp(x,y,window=w1) ppp2 = ppp(x,y, window=owin(ppp1)) # construct window from ppp object owin(ppp1) = owin(ppp2) # give ppp1 the owin of ppp2 That all reads pretty nicely. As long as owin(...) returns an observation window and owin<-(...) assigns an observation window to an object that can validly have one, I don't think you can go wrong. I've probably already tried to do "owin(ppp1)=..." a few times... Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Constructor/extractor.
Preamble: = In spatial point pattern analysis an important component of a point pattern object is the *observation window*. In the spatstat package we have the function owin() to *construct* such a window. It creates an object of class "owin" which can happily exist separately from any point pattern object (object of class "ppp"). However we have at the moment no convenient function to *extract* the observation component of a ppp object, nor have we a really convenient means of (re-) assigning the window component of such an object. We can extract the component via X$window or more suavely via as.owin(X) --- but the latter is rather counter-intuitive and lacks parallelism with other usage. Re-assignment of the observation window component of X can be done either via X$window <- W or X <- X[W]. These are not quite the same. The former may leaves points which are outside of W hanging around. The latter does not suffer from this defect, and is more suave, but is not as intuitive as it might be. I suggested that we could make the owin() function generic, make the current owin() creator function into owin.default(), and build an extractor function owin.ppp() (and an assignment function owin<-.ppp () to assign an observation window to a ppp object). It was pointed out to me that this would make for an unorthodox syntax It is at the very least *unusual* if not unheard of for a function to be used both for *creation* of objects and for *extraction* of components from other objects. Questions: == My questions to R-devel are: (1) Are there any other functions in R that serve this dual role of constructor and extractor? (2) Even if there are no such functions, is there anything intrinsically *wrong* with having a function possessing this somewhat schizophrenic nature? Is it likely to cause confusion, induce syntactical mistakes, create errors, or produce wrong results? Any thoughts, comments, insights or suggestions gratefully received. cheers, Rolf Turner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
