All is clear now.
Thank you for this clarification.
Cheers,
Renaud
On 27/06/2011 15:38, Simon Urbanek wrote:
On Jun 27, 2011, at 8:43 AM, Renaud Gaujoux wrote:
On 27/06/2011 14:27, Simon Urbanek wrote:
On Jun 27, 2011, at 3:17 AM, Renaud Gaujoux wrote:
On 24/06/2011 22:04, John Chambers wrote:
Strictly speaking, that is not meaningful. A class (like any R object) is uniquely referenced by a
name *and an environment*. The name of a package can be used to construct the environment, but
your "character slot" won't identify a class reliably unless the character string has a
"package" attribute.
Look at class(x), for example, from an object from one of these classes. It will have a
"package" attribute identifying the package.
The character string with the package attribute is what you should be storing
in the slot (or else store the class definition---takes more space but is
slightly more efficient).
Thank you for this clarification, I will make my factory method for the
relevant class add the package attribute to the slot.
Storing the class would require recreating the object if the user makes changes
in the class definition. These objects are meant to be used when developing new
algorithms. In this context one expects the user to do multiple tries and
modifications, and I want to ease the process, by using dynamic links to
classes (a character slot) rather than static links (result of getClass).
However, this does not explain why .onLoad does not find the class while
.onAttach finds it, does it?
Is .onLoad evaluated outside the namespace environment, while .onAttach is
evaluated within the namespace?
Look at the default of where - it is the top environment, not the evaluated
one, and in .onLoad the namespace is not attached yet while it is in .onAttach.
Ok, but .onLoad is defined in the source of the package (i.e. within the
package's namespace, am I correct?).
So from what I get from the docs (copy/pasted below), isn't the top-environment
supposed to be the package's namepsace, even if the package is not yet
attached, and its namepace not yet in the search path?
Not in this case, because where is the methods namespace (see the bottom of my
last e-mail - where is not evaluated in environment of your package but in
methods due to the default being removed by isClass). I would say this is a bug
- changing isClass to the trivial
isClass<- function(Class, formal=TRUE, where = topenv(parent.frame()))
!is.null(getClassDef(Class, where))
has the desired effect.
Cheers,
Simon
from ?isClass
" where: The environment in which to modify or remove the definition.
Defaults to the top-level environment of the calling function
(the global environment for ordinary computations, but the
environment or name space of a package in the source for a
package).
When searching for class definitions, ‘where’ defines where
to do the search, and the default is to search from the
top-level environment or name space of the caller to this
function."
from ?topenv
"‘topenv’ returns the first top level environment found when
searching ‘envir’ and its enclosing environments. An environment
is considered top level if it is the internal environment of a
name space, a package environment in the search path, or
‘.GlobalEnv’."
Cheers,
S
Possibly @John: it's a bit puzzling that isClass has a default for where yet it
is entirely ignored as getClassDef is called without where. If anyone changes
the default in getDeffClass() then isClass signature will be misleading - is
there a practical reason for this construct? Thanks, S.
###
UNIVERSITY OF CAPE TOWN
This e-mail is subject to the UCT ICT policies and e-mail disclaimer published
on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or
obtainable from +27 21 650 9111. This e-mail is intended only for the person(s)
to whom it is addressed. If the e-mail has reached you in error, please notify
the author. If you are not the intended recipient of the e-mail you may not
use, disclose, copy, redirect or print the content. If this e-mail is not
related to the business of UCT it is sent by the sender in the sender's
individual capacity.
###
###
UNIVERSITY OF CAPE TOWN
This e-mail is subject to the UCT ICT policies and e-mai...{{dropped:5}}
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
