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. > > ### > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
