Christophe,
Thanks for your work; unfortunately, at the same time you were
developing your version, the original function was being extended in the
same direction.
The version of package.skeleton() to be included in the 2.7.0 release of
R will deal with S4 classes and methods.
When you have
I think, as of just 2 revisions later (44863) anyway, that problem has
been fixed. Sitting in the methods/R directory:
grep -nH -e isGenericFunction *.R
Grep finished with no matches found at Mon Mar 24 16:55:39
Try updating see if all is well. (r-devel is a moving target,
particularly a
Let's start from a simpler description, because the use of sealed
adds some confusion. Here's a basic version. I have two packages, P2
and P3, with different definitions of myClass.
Classes with the same name on two packages are supposed to work, at
least for generating objects. There is
The problem is at least as old as 2.5.1. Looks like a line disappeared
from trace(), something like:
on.exit(tracingState(tState))
As a result, if an error occurs in the call to trace(), the tracing
state is left FALSE. The workaround is to turn it on explicitly:
tracingState(TRUE)
What's the proposal here? To eliminate double as a class? No
objection from this corner. As I remember, it was put in early in the
implementation of methods, when I was confused about what R intended in
this area (well, I'm not totally unconfused even now).
If this is the proposal, we could
Most of your problems seem related to assigning an S4 class to an
arbitrary object--a really bad idea, since it can produce invalid objects.
Objects from S4 classes are created by calling the function new(), and
in principal _only_ by calling that function. Objects from one class
are coerced
Yes, this is the intended behavior. Nothing to do with implicit
generics, but with some ongoing changes to make class structure and
related classes such as array give trustworthy results consistent with
the S language idea of vector structures. There's a short note in NEWS
about the changes,
Generic functions include a package slot. The concept is that only
one definition of the generic _for a particular package_ should exist.
For various reasons, there may be copies of that generic in multiple
places (from the way namespaces work, e.g.) but the model is that they
are really the
Martin Maechler wrote:
MM == Martin Maechler [EMAIL PROTECTED]
on Sat, 23 Jun 2007 00:36:43 +0200 writes:
{on R-help}
[.]
[.]
Duncan Murdoch
DM You might have better luck with
DM log1p(tasa)
MM
special mechanism.
I'm not against cleaning up the semantics but there would need to be a
clear proposal that wouldn't impose a serious penalty (for example,
always rematching the arguments even when the formal arguments are
identical could be such a penalty).
Herve Pages wrote:
John Chambers
Rossi, Peter E. wrote:
I have developed a package, bayesm, which uses existing classes of
objects. I would like
to add a new class corresponding to objects from this package.
I have been reading about classes and all sources tell me that I should
use
so-called new or S4 classes.
Designing a better data frame is something many people have likely
thought about; I certainly have.
But data frames are so widely used and so central to models and other
software that a major change needs to be done by the user community, or
at least with maximum feedback, IMO.
Also, my prior
object=ur.kpss
object=ur.pp
object=ur.sp
object=ur.za
and summary(lc.df) then works as expected.
So the workaround, other than inserting all the import(methods), etc.
you can think of, seems to be to save/load explicitly.
Seth Falcon wrote:
John Chambers [EMAIL PROTECTED] writes
I haven't had a chance to verify these exact examples, but the likely
explanation is that loading the workspace does not cache the saved
methods. Assuming this is indeed what's happening, the workaround is to
cache them manually by the call:
cacheMetaData(.GlobalEnv)
(after attaching the
Well, at the moment I'm a little confused too. It's not at all as
simple as my previous mail suggested.
Here's what I know, and unfortunately I won't have too much time to look
further for a while.
Starting from a clean folder (no saved workspace):
library(urca)
showMethods(summary)
.
you can think of, seems to be to save/load explicitly.
Seth Falcon wrote:
John Chambers [EMAIL PROTECTED] writes:
I haven't had a chance to verify these exact examples, but the likely
explanation is that loading the workspace does not cache the saved
methods. Assuming this is indeed
Seth Falcon wrote:
John Chambers [EMAIL PROTECTED] writes:
As I mentioned, this relates to writing methods for initialize().
Imagine someone else extends the class Ab, for which you wrote a
method. If they add slots to their class and you do not pass down ...
to callNextMethod
Herve Pages wrote:
More generally I don't see what's wrong with not passing
to callNextMethod all the arguments coming from the call
to new:
setClass(A, representation(toto=integer))
setMethod(initialize, A, function(.Object, toto0) [EMAIL PROTECTED]
- as.integer(toto0);
A problem with callNextMethod, which is caching an inherited method as
if it was not inherited, causing confusion on the next search. Should
be fairly easy to fix, but may be a while before I get time to do so.
By the way, I hope your simplified example does not reflect what happens
in the
Thanks for the typo, it might have taken a while to find this one otherwise!
In 2.5.0 and 2.4patched, the subclass information attempts to be
complete. That subclass information needs to be removed from all
superclasses when the class is redefined, and currently isn't. The
particular
You're conflating 3 different things here: how methods are selected,
how R treats missing arguments, and how the standardGeneric() call is
implemented.
Maybe more relevant, if this question is motivated by a practical need,
you may want to rethink what the generic function does. Nonstandard
IMO, the recommended version is:
setClass(kid2, contains = c(mom, VIRTUAL))
because it's the clearest, using the representation argument only for
defining slots. Better yet, if your virtual classes don't have any
slots defined, use setClassUnion() for mom, with the other classes
members of
No, not a bug.
Inherited methods are never cached until they are needed, for rather
obvious efficiency reasons. See ?showMethods, under argument inherited=
If what you were trying to do was find out what method would be called
for class B without calling it, use selectMethod().
Seth Falcon
, but excluding
ANY from the superclasses used. That's quite a different (and longer)
calculation than showMethods() does, but could indeed be useful.
Seth Falcon wrote:
John Chambers [EMAIL PROTECTED] writes:
No, not a bug.
Inherited methods are never cached until they are needed
Steven McKinney wrote:
Hi Seth,
Thanks for the info - actually one of the things
I like about getMethods is seeing the function
internals
Yes, that's why showMethods() has the option includeDefs=TRUE to include
the definitions. There are other options to look at multiple functions
or
Seth Falcon wrote:
John Chambers [EMAIL PROTECTED] writes:
Yes, that's why showMethods() has the option includeDefs=TRUE to
include the definitions. There are other options to look at multiple
functions or specific classes. Look at ?showMethods
A feature request: it would
Yes, a bug.
The problem is that all generics start off with only 1 active argument
in the signature (for efficiency). As soon as a method is specified
with 1 args in the signature, the number of active arguments is
supposed to be incremented accordingly. But specifying the method for
the
The problem is a combination of a class union definition that includes a
basic type as a member, and is not in a package.
Class numeric is sealed, so at present setClassUnion() doesn't cache
the new superclass in the definition of numeric. In 2.4.0 that
happens when a package is attached
Should now be fixed in r-devel and 2.4 patched.
Iago Mosqueira wrote:
El mié, 04-10-2006 a las 09:52 -0400, John Chambers escribió:
I think the problem in your case comes from the mechanism used to handle
non-standard argument lists; notice that you have added 3 new
arguments
I think the problem in your case comes from the mechanism used to handle
non-standard argument lists; notice that you have added 3 new
arguments. If you look at the body of the resulting method you will see
that the mechanism used to handle this (defining a function .local)
fails to copy the
The convention for documenting S4 methods provides a general way to get
the documentation for a method, given the name of the function and the
name(s) of the classes in the signature:
method?FUN,CLASS1,CLASS2,...
where FUN is the name of the function and CLASS1, etc. are the names of
the
.
On Wed, Sep 27, 2006 at 02:08:34PM -0400, John Chambers wrote:
Seth Falcon wrote:
John Chambers [EMAIL PROTECTED] writes:
There is a point that needs to be remembered in discussions of
accessor functions (and more generally).
We're working with a class/method mechanism
There is a point that needs to be remembered in discussions of accessor
functions (and more generally).
We're working with a class/method mechanism in a _functional_ language.
Simple analogies made from class-based languages such as Java are not
always good guides.
In the example below, a
Seth Falcon wrote:
John Chambers [EMAIL PROTECTED] writes:
There is a point that needs to be remembered in discussions of
accessor functions (and more generally).
We're working with a class/method mechanism in a _functional_
language. Simple analogies made from class-based languages
Probably a bug, but not at all the one you imply. You have found a way
to subvert a guarantee in R that methods for primitives can never be
redefined for basic data types.
As you no doubt found, but didn't show us, so long as you say sqrt(4)
the result is correct. (Your Works should really
It's not likely that S3 methods will ever go away, at least in the sense
that all the code using them would be rewritten. What we can work
towards is to make more of the automated tools work for S3 methods as
well as S4. This will usually involve package owners generating some
information,
Parlamis Franklin wrote:
I am having a bit of a struggle deciding when to use attributes with
S4 objects. Clearly the 'class' attribute will always be present.
But it is not clear to me whether the architects of the methods
package intend that other attributes, such as 'names', will
The document on developer.r-project.org/howMethodsWork.pdf explains why
the two methods are equally close. Please (re)read it.
If you know what methods you want for mixing the two objects, you must
either say so or arrange the classes in an inheritance that includes
both classes.
Robin
1.11.2 1.3.1
Biobase
1.11.34
===
John Chambers wrote:
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
() is not appropriate.
Robin Or is there some workaround that would enable me to do this?
well, yes: As John Chambers has tried to say, you have to teach
your users to use cWithPairs() or c2() or myC() or c.() or any
reasonable name, but not c().
Martin
[[alternative HTML
Sounds like you don't have a version Matrix installed from source for
2.4.0. As mentioned earlier on this list, the caching mechanism has
changed for methods, and all packages need to be installed from source
to get the correct objects.
Works fine for me with an installation of Matrix from
to c()
is a brob?
On 5 Sep 2006, at 16:47, John Chambers wrote:
(Before someone else can embarrass me with the reference)
There is a variant on the c() example discussed in Programming with
Data, page 351, for the function max().
John
John Chambers wrote:
It's all very well
It's all very well to go on about efficiency, but the purpose of
statistical computing is insight into data, not saving CPU cycles (to
paraphrase Dick Hamming).
S3 methods do some things fine; other tasks need more flexibility. One
should ask what's important in a particular application and
(Before someone else can embarrass me with the reference)
There is a variant on the c() example discussed in Programming with
Data, page 351, for the function max().
John
John Chambers wrote:
It's all very well to go on about efficiency, but the purpose of
statistical computing is insight
A recent revision (svn version 39077) has introduced an internal flag (a
bit in the C structure) that is turned on by the code that generates
objects from an S4 class.
There are corresponding tests for an S4 object, isS4() in R and
IS_S4_OBJECT() in C. These are fast and reliable, and should
General comments. A number of packages will likely be showing weird
warnings on attach() about packages being out of date. Likely caused by
a confusion when two packages define the same generic. The bug is being
worked on, but there are some issues of package design that will need
A revision of r-devel 2.4.0 is being committed today with changes to
method and class management.
The changes are internal but extensive. All packages that use S4
methods and classes need to be reinstalled from source to use the new
version.
The main effects are to speed up method caching
John Chambers wrote:
A revision of r-devel 2.4.0 is being committed today with changes to
method and class management.
The changes are internal but extensive. All packages that use S4
methods and classes need to be reinstalled from source to use the new
version.
A footnote
Henrik
On 8/30/06, John Chambers [EMAIL PROTECTED] wrote:
A revision of r-devel 2.4.0 is being committed today with changes to
method and class management.
The changes are internal but extensive. All packages that use S4
methods and classes need to be reinstalled from source to use the new
Well, two comments, in two non-compatible directions.
1. I have to say that I find the idea of using + to paste character
strings together aesthetically ugly.
IMO, one thing that makes functional object-based languages attractive
is that the generic function retains a consistent _function_,
hadley wickham wrote:
Providing the ability to write assignment functions that don't duplicate
is a more urgent problem.
You mean, for end-users? It can be done via primitives.
Isn't this sort of a run-time optimisation? I thought R generally
followed the functional
but for which
length(x), x[], x[1] and other computations go through with no
complaints. And all without the benefit of any methods, S3 or S4. Just do
x - NULL
Seth Falcon wrote:
John Chambers [EMAIL PROTECTED] writes:
When I was introducing the special type for S4 objects, my first
When I was introducing the special type for S4 objects, my first
inclination was to have length(x) for those objects be either NA or an
error, along the lines that intuitively length(x) means the number of
elements in the vector-style object x. However, that change quickly
was demonstrated to
source.
Also, a note about future changes: There will likely be two more
changes to S4 code in the next few weeks: an internal bit to mark S4
objects for testing, and a new version of method dispatch designed to
fix some logical flaws and to be more efficient.
John Chambers wrote:
The default
If you want to avoid checking your objects for validity, create them as
default objects and then set the slots.
validObject is only called if new() gets optional arguments.
and it's not called when a slot is assigned (because in some cases an
invalid intermediate object will exist, between two
Umm, maybe we should step back a bit here.
There are two points being made, both of which I think are reasonable,
but they just don't happen to work together.
1. Environments are special objects in R. In fact they are the
essential way directly in R to implement reference semantics. Every
This may be related to the problems with greedy search for inherited
methods discussed previously on this list (or may not, it's a bit
different).
In any case, the likely fix will be a substantial cleaning up of generic
functions hoped for in the next release.
Meanwhile, Keep it simple is the
The bug should now be fixed. The actual change is very small, but it
enforces a semantic definition that may be relevant, so we should
discuss it.
The question is: what method does callNextMethod() refer to? The
definition now enforced is: the next method is the method found for
the
It's a bug resulting from the combination of:
1. multiple recursive levels of callNextMethod()
2. nonstandard arguments in the method definition; that is, (.Object,
x) vs .Object, ...) for the generic.
Specifically, the callNextMethod code tries to build up a list of
excluded classes, but in
What a delicious example! (I'm taking the liberty of sharing it with
r-devel, since it raises some good issues.)
You have two questions, presumably:
1 - how could the order of the setMethod calls make a difference in the
results?
2 - what's causing the infinite loop how could it be avoided,
As I think Seth told you before, if you want to control the order of
inheritance at the same level, you need to use the intended order in the
contains= argument to setClass. In your example (retaining the class
union, although it's not required, the superclass could just be an
ordinary
(diverted to r-devel)
The problem seems to be rather that loading of the saved image takes
place _after_ the packages are attached. So nothing that the methods
package does in its initialization will see the relevant type converters
or other methods objects.
More generally, loading into
From your description of the application, it sounds like you would be
better off just forcing + to behave as you want. Using inheritance is
a much more powerful mechanism can introduce results you don't want,
as it seems to have in this case.
An important point about using inheritance is
Seth Falcon wrote:
Hi John,
I found your comments helpful, even though this isn't _my_ question.
But now I have one of my own :-)
John Chambers [EMAIL PROTECTED] writes:
Of course, I could also declare explicitly + methods for signatures
c(Exp, Exp), c(Exp, Gammad), and c(Gammad, Exp
David had reported this to me privately earlier today. I'm fairly sure
the problem is caused by an invalid factor variable, with numeric rather
than integer data. At the moment I'm checking a patch to scan.c that
checks this to avoid a segfault.
If that's not the problem I'll report back to
Two recent changes have been committed to r-devel, related to
discussions on this list earlier:
1. setOldClass() has an argument prototype= to specify the default
object for the class. If provided, the S3 class can be a slot in an S4
class, with a valid default object.
(It's still not going
In fact there is a heuristic test that is cheap and reasonably
reliable. The class attribute generated for S4 objects itself has an
attribute, package. A C-level test for the existence of that
attribute is cheap enough, I would think, that most anti-S4 users
wouldn't notice it in match(),
Seth Falcon wrote:
On 3 Jan 2006, [EMAIL PROTECTED] wrote:
It's legal to have virtual classes as slots, but yes, the slot is
NULL in the prototype for the new class, unless the user specifies a
value. In your case, providing a non-null prototype for the
data.frame slot might be the desired
I very much share Duncan's concern that research in statistical software
should move ahead, and contribute to some of the exciting new uses of
data we see.
R is the most striking success in statistical software over the last
decade, in terms of the variety and quantity of statistical
Your description is a bit too vague to be sure, but it sounds as if
you're trying to do something that breaks the basic namespace idea.
Paul Roebuck wrote:
The package I'm working on can extract data from external
packages but would otherwise have no dependency on them.
However, I desire to
First, anyone planning to debug methods should consider the general form
of the trace() function with signature= to say what method to trace, and
some suitable interactive function such as browser or recover to
examine the computations. See ?trace
In this example, something like:
Well, let's say R is currently picky when only a prototype is supplied.
The following is either a workaround or a revised, fussier requirement
for the example mentioned, depending on your interpretation.
R setClass(sequence, representation(.Data=numeric),
prototype=numeric(3))
[1] sequence
R
for the initialize() method. Leave them as .Object,
... and extract the id= component.
dotArgs - list(...)
id - dotArgs$id
Or, wait for a fix. There should at least be one in r-devel sometime
fairly soon.
Paul Roebuck wrote:
On Fri, 5 Aug 2005, John Chambers wrote:
Paul Roebuck wrote:
Can
Paul Roebuck wrote:
On Wed, 20 Jul 2005, John Chambers wrote:
Paul Roebuck wrote:
Is it possible for S4 to (continue) dispatch to a class
created during dispatching? The code below doesn't work;
is this not possible or have I ommitted something?
doesn't work? This is not helpful. Please
201 - 274 of 274 matches
Mail list logo
