Skip to content
Prev 27698 / 63424 Next

NAMESPACEs and S4 classes

Thank you for the explanation; I saw that class definitions were
stored in package-level .__C__* and in a global cache
methods:::.classTable, but was not sure which was meant to be
definitive.

I'm hoping your bug fix will address identically named sealed classes
in different packages -- I hope to use 'sealed' as a way to reduce
programming errors associated with unintentionally overwriting
existing class definitions (the classes are generated
programmatically, and a name conflict escaped my notice; I thought a
'better practice' would be to seal class definitions that I did not
intend to change).

The class hierarchies I am working with are large. I hope to avoid
regenerating them each time the package is loaded, e.g., using a lazy
load data base built when the package is installed. I can see how this
might work when class definitions are in package-level variables
.__C__*, but am less clear about how lazy loaded class definitions
might be added to a globally cached class table.

My more ambitious hope is to manage identically named classes from
separate hierarchies in the same package, e.g., by placing each
hierarchy in a separate environment (with attribute 'name' set, so
environmentName() returns something sensible). I realize this does not
work with the current implementation, but offer it as a potential use
case.

Thank you again for your help.

Martin

John Chambers <jmc at r-project.org> writes: