On 05/12/2015 05:31 AM, Martin Maechler wrote:
Martin Morgan
on Mon, 11 May 2015 10:18:07 -0700 writes:
> On 05/10/2015 08:19 AM, Martin Morgan wrote:
>> Loading an S4 object from a file without first loading the library
sometimes (?,
>> the example below and actual exampl
> Martin Morgan
> on Mon, 11 May 2015 10:18:07 -0700 writes:
> On 05/10/2015 08:19 AM, Martin Morgan wrote:
>> Loading an S4 object from a file without first loading the library
sometimes (?,
>> the example below and actual example involves a virtual base class and
the s
On 05/10/2015 08:19 AM, Martin Morgan wrote:
Loading an S4 object from a file without first loading the library sometimes (?,
the example below and actual example involves a virtual base class and the show
generic) leads to incorrect dispatch (to the base class method).
The attached package repr
Is setOldClass the solution?
e.g.
x <- list()
class(x) <- "foo"
setGeneric("bar", function(x) "bar generic")
setOldClass("foo")
setMethod("bar", "foo", function(x) "bar foo")
bar(x)
On 7 October 2014 10:00, Dario Strbenac wrote:
> Hello,
>
> I am writing an interface to some functions from the
On 9/30/11 12:48 AM, Edzer Pebesma wrote:
Thanks, John!
I did not manage to figure out how the strict= works, but changed class
inheritance such that simple inheritance did not take place.
I see you're advocating to use the contains= to stress inheritance; back
in 2005, I followed the green b
Thanks, John!
I did not manage to figure out how the strict= works, but changed class
inheritance such that simple inheritance did not take place.
I see you're advocating to use the contains= to stress inheritance; back
in 2005, I followed the green book, which did not yet have this.
If I n
The distinction here is "simple inheritance" ("Software for Data
Analysis", p. 346). Your first example is simple inheritance (would be
clearer if you used the contains= argument). In the second version you
supply an explicit coerce method, so method dispatch can no longer just
pass in the o
As a follow-up, I managed to isolate the problem I sent earlier this
week, and reduced it to a small case (I'm using R 2.13.1,
i486-pc-linux-gnu (32-bit)).
The following script does what I expect:
setClass("A", representation(x = "numeric"))
setClass("AB", representation("A"))
setGeneric("doNot
Hi Martin,
>> However, when I put all these in a package with Depends field in
>> DESCRIPTION having: methods, pixmap, and with the following namespace:
>>
>>
>> importFrom("graphics", "plot")
>> exportClasses("myclass")
>> exportMethods("plot")
>>
>>
>> things stop working (this is from package t
Hi Michał --
Michał Bojanowski writes:
> Hi,
>
> I ran into the following peculiarity involving S4 method dispatch and
> namespaces.
>
> I develop a package which have a namespace and which depends on 'pixmap'
> package, which itself does not have a namespace.
>
> Now, in my package I have a cla
I have tried it on the patched version of R, and it works now.
Thanks,
Jan
Van: John Chambers [mailto:[EMAIL PROTECTED]
Although there is not enough information to be sure, this may be related to an
issue uncovered in other testing, for which a patch has ju
Although there is not enough information to be sure, this may be
related to an issue uncovered in other testing, for which a patch has
just been committed.
The issue arises if the same generic function is defined in several
packages. For example, Matrix and msbase both have methods for the
p
Your suggestions worked ok in the example, but in my case there is yet another
package that implements a plot method.
Now the plotting from within the package works, but plotting from outside the
package, on the console, gives an error as if plot.default is invoked.
> class(myplot)
[1] "gt.barplo
Good example.
The basic problem is in the NAMESPACE file:
importFrom(graphics, plot)
But the version of plot() in the graphics package is not a generic
function. Therefore, when your mpplot() calls it there is no method
dispatch.
You need to import the generic version of plot() from minipk
14 matches
Mail list logo
