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 show what you got and what
you expected. The result below is
Quite right. There is code in the evaluator that copies default values
from the method into the promise for a missing argument, when the method
is being evalutated.
The catch seems to be that there is no promise unless SOME default was
included for the argument in the generic.
So either we ne
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 possib
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:
trace("
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] "sequenc
nts 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:
>
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 t
e= to setIs()). Comparing the
two calls and looking at the documentation for setIs should explain
where the warning comes from. But in any case, nothing to worry about.
John Chambers.
Sebastian Luque wrote:
> Hello,
>
> Below is what I got running the examples from `setClass
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 technolog
S3 classes are treated as virtual classes, with or without a call to
setOldClass()--the purpose of setOldClass() is to make method dispatch
with S3 inheritance work.
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 specif
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 th
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(), c
On 7/11/10 9:08 PM, Daniel Murphy wrote:
R-Devel:
When I get the data part of an S4 class that contains="data.frame", it gives
me a list, even when the "data.frame" is the S4 version:
d<-data.frame(x=1:3)
isS4(d)
[1] FALSE # of course
dS4<-new("data.frame",d)
isS4(d
t to contradict
my previous mail) you probably wanted to turn your object into a
data.frame. If so, best to say so:
> as(z, "data.frame")
Object of class "data.frame"
x
1 1
2 2
3 3
and, for that matter:
> as(z, "list")
[[1]]
[1] 1 2 3
-Dan
O
Note that S4 classes extend "environment" and other reference types, by
using a hidden slot. You can then add other slots. So, with some extra
work:
> setClass("myEnv", contains = "environment",
+ representation(myName = "character"))
[1] "myEnv"
> Foo <- new("myEnv", myName = "Foo")
> Foo
An
A new facility has been added to r-devel for experimenting by authors of
packages.
The idea is to insert modified code from the package source into the
running package without re-installing. So one can change, test, change,
etc in a quick loop.
The mechanism is to evaluate some files of sourc
There does indeed seem to be a bug in the C code that implements
callNextMethod, with the effect of adding a spurious index to calls to
the primitive `[` code with more than 2 subscripts.
The message "incorrect number of dimensions" is telling the truth, the
primitive code gets 4 subscripts in
The problem in this example is (plausibly) that the argument evaluation
code in method selection itself uses an internal C-level version of
try(), overriding the user's setting.
If this is the bug, I'll have to defer to more expert advice on whether,
and if so how, the code can adjust for the
Thanks for the report. Should now be fixed in r-devel and 2.12
patched (rev 53383).
Please do report any cases where a subclass of environment doesn't
work. There are some known cases in locking and active binding, that
will be fixed in due course.
The workaround for any such problem is u
#x27;t use constructions like e...@.xdata. This depends on the
current implementation and is not part of the user-level definition. Use
as(env, "environment") or equivalent. (In this case, the assignment of
the object's own environment was irrelevant to the error.)
John Chambers
On
fficiently standardized among languages that it has a reasonable
chance to stay compatible.
Other comments below.
John
On 10/22/10 7:21 AM, Jon Clayden wrote:
Dear all,
First, many thanks to John Chambers, and anyone else who was involved,
for the new support for "reference classes&
nv
> Error in environment(tf) <- env :
> replacement object is not an environment
>
>
> Vitally.
>
>
> John Chambers writes:
>> This is a problem related to the introduction of exact= into the [[ and
>> [[<- functions. As Bill says, the current
&g
One correction:
On 10/22/10 10:55 AM, John Chambers wrote:
.
As a suggestion, it would be nice if the accessors() method could be
used to create just "getters" or just "setters" for particular fields,
although I realise this can be worked around by removing the unwante
For reference classes (and other R code) it's important to distinguish
the application program interface from the implementation. Anyone is
welcome to explore the implementation, but we reserve the right to
change that, particularly with a new feature in the language.
The draft API for refer
On 10/24/10 2:53 AM, Vitalie S. wrote:
Thank you for the answer, John.
John Chambers writes:
Second point first: The actual environment of a function is tightly
bound to low-level implementation at the C level. Only a _really_
strong practical argument would even tempt us to change that
On 10/24/10 1:43 PM, Vitalie S. wrote:
John Chambers writes:
On 10/24/10 2:53 AM, Vitalie S. wrote:
Thank you for the answer, John.
John Chambers writes:
Second point first: The actual environment of a function is tightly
bound to low-level implementation at the C level. Only a
mmy!
On 10/26/10 4:57 AM, Jon Clayden wrote:
On 23 October 2010 00:52, Jon Clayden wrote:
On 22 October 2010 18:55, John Chambers wrote:
As a suggestion, it would be nice if the accessors() method could be
used to create just "getters" or just "setters" for particular fields,
Good diagnoses.
This thread brought up a point or two that needed some fixes to the
documentation and code. They should be in r-devel and 2.12 patched
(from rev. 53471).
Briefly:
- Initialization methods should take account of future subclasses to
your class by including and passing on the
`[[<-`, that is. Right, the primitive code is not retaining the
subclass information.
Should be fixed in r-devel and 2.12 patched from revision 53547.
Thanks for the catch.
On 11/10/10 3:32 AM, Vitalie S. wrote:
Dear Developers,
A recently patched [[ for environment class returns a blank en
The problem here is that the primitive for `$` does not use standard R
evaluation on its second argument, so when it is selected as the next
method the call is effectively x$name regardless of the original call.
If possible, I would avoid such cascaded calls of methods for `$`,
precisely becau
On the subject of clarification, Reference Classes are not really an
"addition" to S4. They are a programming interface to allow OOP (i.e.,
C++ or Java-style) programming in R.
They do use some S4 tools but rely more on some valuable existing
techniques for dealing with environments, such as
As I posted previously in this same thread, reference classes are _not_
an addition to S4, but provide an interface to the "classical" OOP
programming model in R, via environments and tools for those (and, also,
via some S4 techniques). The current version of the Rcpp package
illustrates how t
Well, it's an interesting idea, and the current implementation would fit
with it.
One catch is that it goes against any obvious notion of checking for
valid objects (admittedly, there are some difficulties in that already
with active bindings being used).
Another issue is that in normal R pr
>>
>> What am I doing wrong here?
Not using a recent enough version of R probably (and not telling us what
version you are using).
The warning (not an error) should not appear in current r-devel or
2.12-patched. In other words, works fine for me.
John
On 11/21/10 3:40 PM, Janko Thyson wrot
No reference class method explicitly does this, but it's a natural
utility. Some form of $copy() will be added. It needs a shallow/deep
option; i.e., if a field is itself a reference class object, should that
field be cloned as well. The full reflectance available should make a
single method
Hi Marc,
Sort of one out of two, but very helpful.
On 1/28/11 11:01 AM, Marc Carpentier wrote:
Dear r-devel-list, dear John Chambers,
I'm trying to learn OOP-possibilities in R and I was going through the
documentation 'ReferenceClasses {methods}' (great work, by the w
You don't say, but my guess is you created the package without a namespace.
For reasons that are not too clear at the moment, the namespace seems to
be needed. At any rate, replicating your experiment with the argument
namespace=TRUE to package.skeleton() worked:
> require(TestClass2)
Loadin
Yes, as noted in my previous mail, which crossed yours. If you included
the TestClass in a code_file= in the package skeleton, the default
NAMESPACE file from package.skeleton() will do that for you:
exportPattern("^[[:alpha:]]+")
exportClasses(
"TestClass"
It's certainly true that _if_
No worries, and we will get rid of the warning message.
Certain of the S4 classes require methods for particular primitive
functions. If a subclass of one of those classes is loaded from a
package, then we need to turn on method dispatch for the corresponding
primitive(s). For efficiency, th
PS: this is another glitch that arises when you don't use NAMESPACE
files. If the .requireCachedGenerics is in a NAMESPACE and not
exported, the conflict does not arise.
On 2/15/11 12:52 PM, John Chambers wrote:
No worries, and we will get rid of the warning message.
Certain of t
The "names" slot is not part of the basic vector types/classes.
If you want to extend named lists, extend the class "namedList":
> getClass("namedList")
Class "namedList" [package "methods"]
Slots:
Name: .Data names
Class: list character
Extends:
Class "list", from data part
Cla
There is a virtual class "refClass" that all reference classes subclass,
so is(x, "refClass") is the natural test, as in:
> foo <- setRefClass("foo", fields = "bar")
> x <- foo$new()
> is(x, "refClass")
[1] TRUE
On 3/10/11 7:40 AM, Jeffrey Horner wrote:
Hi all,
I've constructed the following
Look at ?ReferenceClasses for this OOP paradigm in R, which is quite
different from the functional paradigm of S4 methods.
On 4/6/11 7:54 AM, A Zege wrote:
Apologies for asking something that is probably very obvious, i just started
with S4 classes and i guess i am not finding documentation tha
This is a good wish-list item. The natural mechanism would be a version
of the standard trace() function as a reference method with the same
arguments as the current trace(), minus those that make no sense. So:
xx$trace(edit, browser)
for example, to trace execution of the reference method
Good to know. However, _please_ don't use the horrible kludge in the
attr(..) expression. From my experimenting, it worked fine just to say:
mtrace(edit, from = xx)
and even if that did not work, from = as.environment(xx) is identical in
effect to the attr() expression and means something.
The warning is there because all is not "just fine", in general and in
particular not in your example.
If a superclass is not virtual, the prototype object for the new class
must have a member of that class in the appropriate slot. How could it
do so in this case? As a result, your class wil
You're confusing functional and OOP-style methods.
Since you define an OOP-style method, you need to invoke it in OOP style.
With your example:
> tmp$`[`("random")
[1] -1.439131143 -0.630354726 0.822006263 -0.651707539 0.475332681
[6] 0.002680224 1.539035675 -0.117609566 2.066227300 1.
Yes, as presented on that site it makes a little more sense:
"While experimenting with the new reference classes in R I noticed some
odd behaviour if you use the "[[ ]]" notation for methods
(X[["doSomething"]] instead of X$doSomething). This notation works for
fields, but I initially thought
On 5/1/11 3:37 PM, Martin Morgan wrote:
On 05/01/2011 03:09 PM, John Chambers wrote:
Yes, as presented on that site it makes a little more sense:
"While experimenting with the new reference classes in R I noticed some
odd behaviour if you use the "[[ ]]" notation for methods
(
On 5/3/11 2:39 PM, Hadley Wickham wrote:
Part of the motivation for the reference classes was to bring a general OOP
view to R. One can start from some essential concepts of objects and their
properties, inheritance and class definition, as have evolved over a very
long time.
Next, there is a f
Interesting idea.
One approach would be to test against the _environment_ of the prototype
object in the class definition. Since the initialize method for a
reference class must call new.env(), one knows that a real object from
the class has a different environment. Using that fact one could
On 5/4/11 9:24 AM, Hadley Wickham wrote:
Are you familiar with "Concepts, Techniques, and Models of Computer
Programming" by van Roy and Haridi? That's what really helped me to
understand the strengths and weaknesses of the various styles of
programming.
Thanks, I wasn't. Yes, interesting sim
It makes no sense to replace the .self field: that field is initialized
to be a reference to the object. If you change it, it's no longer that
reference.
There are many things wrong with your example, so it's better to take a
very simple version:
> mkTest <- setRefClass("test",fields = lis
that useful performance tools can be designed.
If you can provide us with examples that we can use and share, please
send a description to:
Justin Talbot
As examples accumulate, the plan is to make them available to the
community---details to be worked out.
Thanks in advance,
John Cha
Good suggestion for this case.
But the general problem is tricky. What about reference objects
contained in attributes or slots of other objects, etc? What is needed
for total copying is a switch in the low-level duplication code that
says to copy reference objects. It's also possible that
This is basically a case of a user error that is not being caught:
On 5/14/11 3:47 PM, Hervé Pagès wrote:
Hi,
I was stumped by this. The two S4 objects below looked exactly the same:
> a1
An object of class "A"
Slot "aa":
integer(0)
> a2
An object of class "A"
Slot "aa":
integer(0)
> str(a
;character"), contains = "integer")
[1] "B"
> b <- new("B", 1:5)
> names(b) <- letters[1:5]
> b
An object of class "B"
[1] 1 2 3 4 5
Slot "names":
[1] "a" "b" "c" "d" "e"
> nam
On 5/16/11 10:09 AM, Hervé Pagès wrote:
On 11-05-16 09:36 AM, John Chambers wrote:
You set up a names slot in a non-vector. Maybe that should be allowed,
maybe not. But in any case I would not expect the names() primitive to
find it, because your object has a non-vector type ("S4").
character
Extends:
Class "list", from data part
Class "vector", by class "list", distance 2
Known Subclasses: "listOfMethods"
> xx <- new("namedList", list(a=1,b=2))
> names(xx)
[1] "a" "b"
> names(xx) <- c("D
On 5/17/11 9:53 AM, Hervé Pagès wrote:
On 11-05-17 09:04 AM, John Chambers wrote:
One point that may have been unclear, though it's surprising if so. The
discussion was about assigning names to S4 objects from classes that do
NOT have a formal "names" slot. Of course, having a
Right, but Michael's point is valid. It's the standard bug from having
to explicitly check for a non-empty list before taking names(x).
Will fix. Thanks for the catch.
John
On 6/1/11 9:21 AM, William Dunlap wrote:
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-deve
Well, your mail is unclear as to what you expected, but there is one bug
shown by your example.
The behavior of S4 classes is sensible, at least as far as the example
shows:
> setClass("A", representation(x="ANY"))
[1] "A"
> setClass("B", contains="A", representation(x="character"))
[1] "B"
tation(x="character"))
[1] "B"
> new("B", x = "abc")
An object of class "B"
Slot "x":
[1] "abc"
Thanks for addressing this!
Regards,
Janko
On 03.06.2011 19:13, John Chambers wrote:
Well, your mail is unclear as to wha
This is a bug, medium-subtle, but also raises an interesting software
design point.
The Bug:
Nothing specific about "ANY" and "missing", but the issue is whether the
method was inherited (the "ANY" case) or defined directly (the "missing"
case).
Generic functions keep a cached table of disp
As it says on the help page ?ReferenceClasses:
All reference classes inherit from the class "envRefClass"
So,
is(x, "envRefClass")
And, less well documented but less typing:
is(x, "refClass")
also works.
On 6/6/11 9:48 AM, Janko Thyson wrote:
Dear list,
is there a shortcut-function to c
implemented.
John
On 6/7/11 6:15 AM, luke-tier...@uiowa.edu wrote:
On Mon, 6 Jun 2011, John Chambers wrote:
This is a bug, medium-subtle, but also raises an interesting software
design point.
The Bug:
Nothing specific about "ANY" and "missing", but the issue is wh
em to have been
encountered before your example. We won't add the warning in the
immediate future, and as Luke pointed out, even Dylan just advises.
This may be more a matter for a "code tools" approach. So not to worry
just yet!
John
Iago
On Tue, Jun 7, 2011 at 7:06 PM, Joh
The bug should be fixed in r-devel and 2.13 patched, as of svn rev. 56090.
John
On 6/7/11 12:42 AM, Iago Mosqueira wrote:
On Mon, Jun 6, 2011 at 11:28 PM, John Chambers wrote:
This is a bug, medium-subtle, but also raises an interesting software design
point.
The Bug:
Nothing specific
Good catch.
Here's the problem. To save space and time, reference methods are not
all copied to every object in the class. Instead, the methods are
copied in when first accessed. Methods are functions which use the
object as their environment. So that is the sense in which "lazy
evaluati
The workaround is to use the package's namespace, as you did. That's
one of the reasons why pkgname is an argument to .onLoad().
Depending on what you want to do, you can either use the namespace as an
argument where= or get the class definition from the namespace and use
it in place of the c
nd when the installation sources
the script prepare the package for lazy loading.
- why things seemed to work ok in R-2.12.1 at the installation loading
check, but do not work when loading the package from an R session?
Could you please briefly give some explanations or pointers?
Thank you.
Bests,
I don't have anything to suggest on your specific example but perhaps
these two notes are relevant.
1. As is mentioned in the documentation, it's generally a bad idea to
write S4 initialize() methods for reference classes, rather than
reference class methods for $initialize():
"a reference m
In principle, two separately developed packages could use the same class
name, and a user could then attach both and attempt to use methods for
both classes.
That has never worked, but some changes have been added to r-devel to
handle this case. The changes involve extending the "signature" c
cate classes do exist, a utility findDuplicateClasses(details =
FALSE) will give the names of the duplicated classes. It's not yet
exported so you need to call methods:::findDuplicateClasses()
John
On 7/21/11 10:29 AM, John Chambers wrote:
In principle, two separately developed package
On 7/25/11 12:07 AM, Martin Maechler wrote:
John Chambers
on Sun, 24 Jul 2011 14:58:23 -0700 writes:
> A point that has come up a couple of times with the new
> test is that two classes from two packages may be "the
> same class". Should that turn o
In R-devel, a recent change (Rev. 56572) makes assignments to fields in
reference classes consistent with assignments to slots in S4 classes,
when the field was declared with a class in the call to setRefClass().
The value assigned must come from the declared class for the field, if
any, or fr
There is also an item in the NEWS file:
Field assignments in reference classes are now consistent with
slots in S4 classes: the assigned value must come from the declared
class (if any) for the field or from a subclass.
On 8/5/11 7:24 AM, Simon Urbanek wrote:
It's worth actually reading
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
r
empty name fields. And easier to discuss (e.g., section 9.3 of SoDA).
You're hardly the only sinner in the flock. I imagine many packages on
CRAN would have failed by now if there was a problem. I only complain
about it when feeling fussy.
John
.
On 09/18/2011 11:04 PM, John Chamber
I understand Hadley's point; it's a consequence of the modification of the
environment of the ref. class methods.
Good point, but it seems we can make that an option (there are advantages to it
of code quality and ease of writing, when it works);
Let's discuss possibilities, off-list until thin
We do need an explicit method here, I think.
The issue is that as() uses methods for the generic function coerce() but
cannot use inheritance in the usual way (if it did, you would be immediately
back with no change, since "integer" inherits from "numeric").
Copying in the general method for co
"numeric" as a virtual class and "double" as a type/class.)
On Dec 11, 2015, at 1:25 AM, Martin Maechler wrote:
>>>>>> Martin Maechler
>>>>>>on Tue, 8 Dec 2015 15:25:21 +0100 writes:
>
>>>>>> John Chambers
>
e to go with
that (on r-devel), advertising that it may change the effective definition of
some classes.
But I can sympathize with choosing 1, 2 or neither.
John
PS: Until Jan. 4, I may be even poorer at replying than usual, while getting
the current book off to the publisher.
On Dec 19, 201
1] "integer"
>
> My wish for 2016: that selectMethod() always tells the truth. For
> example selectMethod("coerce", c("integer", "numeric")) doesn't
> in a fresh session, only after you call as(1L, "numeric")). Full
> story here
The Wikipedia statement may be a bit misleading.
S was never open source. Source versions would only have been available with a
nondisclosure agreement, and relatively few copies would have been distributed
in source. There was a small but valuable "beta test" network, mainly
university stati
ot; %in% search()
>>[1] FALSE
>
>> This may be intentional, but the behavior seems surprising
>> and could be responsible for the behavior outlined
>> earlier.
>
> Yes, the behavior you outlined earlier is buggy, and I also have
> seen similar bugous beh
p fails, and we end up
> caching the wrong inheritance information.
>
> Thanks,
> Kevin
>
> On Sun, Jul 31, 2016 at 5:12 AM, John Chambers wrote:
>> (Just returning from the "wilds" of Canada, so not able to comment on the
>> specifics, but ...)
>>
>>
341
>
>> I get a list whereas if Pi is an ordinary matrix I get a
>> vector. Is this intentional?
>
> Well, no. But it has been "unavoidable" in the sense that it had not
> been possible to provide S4 methods for '...' in the "remote"
> past, w
It's hard to see how repeated dispatch on the same classes can be that
slow, _if_ the function being called each time is itself doing some
substantial work.
The first call (in a session) with a particular signature searches for
inherited methods and stores the method found in a table. The fol
And just in case anyone is curious about the history, return() with
multiple arguments was legal in S2 but the syntax in the blue book had
only return(expr), whether enforced or not in the code.
John
On 8/13/13 11:42 AM, luke-tier...@uiowa.edu wrote:
Both codetools and the compiler should
Don't use .onLoad() to set class (or other nontrivial) information at load
time. Use setLoadActions(), which was created exactly to get around the
limitations of .onLoad().
For an example, see the Rcpp package, which uses this to set up load-time C++
linkages.
John Chambers
On Oct 3,
The basic tool is setLoadActions(), which takes a function definition, with the
package's namespace as its argument. Read ?setLoadActions
There is no such thing as setLoadFunction, as far as the standard code in R.
While you haven't defined "didn't work", an off-the-top-of-the-head idea would
Very good report.
Should be fixed in the development version for 3.1.0 and in 3.0.2 patched. (svn
revision 64076).
John
On Oct 18, 2013, at 8:51 AM, Karl Forner wrote:
> Hi all,
>
> I have a problem with a package that imports two other packages which both
> export a method for the `[` prim
One additional point to Michael's summary:
The "methods" package itself should stay in Depends:, to be safe.
There are a number of function calls to the methods package that may be
included in generated methods for user classes. These have not been revised to
work when the methods package is n
is to put methods in Depends.
Or at least, import the package rather than just the obvious functions.
John
On Oct 25, 2013, at 3:46 PM, Paul Gilbert wrote:
>
>
> On 13-10-25 05:21 PM, Henrik Bengtsson wrote:
>> On Fri, Oct 25, 2013 at 1:39 PM, John Chambers
>> wro
This was previously reported and fixed. See the NEWS file and bug
report 15481.
On 10/29/13 9:19 AM, Karl Forner wrote:
Dear all,
Consider this code:
library("data.table")
unloadNamespace('data.table')
It produces some warnings
Warning in FUN(X[[1L]], ...) :
Created a package name, ‘201
Previously reported and fixed in 3.0.2-patched (Bug 15481). Unless there is a
3.0.3, you will have to wait for 3.1.0.
On Dec 19, 2013, at 10:19 AM, Winston Chang wrote:
> I've been seeing warnings when unloading packages. They can be seen with
> the shiny and sp packages, among others (this is
On Jan 3, 2014, at 9:46 AM, Hadley Wickham wrote:
> On Thu, Jan 2, 2014 at 7:16 PM, Henrik Bengtsson
> wrote:
>> Does it make sense to talk about the class of the output of
>> substitute(...)? I'm puzzled by the following outputs:
>>
>> ee <- list(
>> A = substitute( a <- 1 ),
>> B = subst
I haven't looked at this in detail, but my guess is the following is the
distinction:
A simple call setGeneric("sort") makes a generic of the existing
function _with the existing package_:
> setGeneric("sort")
[1] "sort"
> sort
standardGeneric for "sort" defined from package "base"
function
I'm sympathetic to the problem. But, whatever my opinion, it's not likely that
the basic R paradigm with respect to S3/S4 methods will change much, and
certainly not for a year.
Meanwhile, let's remember the essential idea. Every function has a
corresponding implicit generic form (well, parti
1 - 100 of 304 matches
Mail list logo
