1

Suppose I want to find out in which package a class is defined, e.g. say (defclass x ()()) is defined in p1. One way could be to get the package via (symbol-package 'x). the problem with this solution is that x is exported in a different package p2. Any other suggestions?

Rainer Joswig
  • 136,269
  • 10
  • 221
  • 346
user1222310
  • 13
  • 2
  • 12
    classes are not really defined in packages. Only symbols are. The name of a class is a symbol, but it can be any symbol. There is no need that this symbol is from the package which was the default package at read time. – Rainer Joswig Feb 21 '12 at 03:41
  • You...may want to post that as an answer. – Inaimathi Feb 21 '12 at 17:56
  • ok. I see how the question is ill posed to some extend. How do i find out in which package the (defclass x ..) appeared (was loaded or compiled)? – user1222310 Feb 22 '12 at 07:30

1 Answers1

1

As Rainer Joswig said, classes aren't defined in packages; symbols have packages and the name of a class is a symbol.

If you want to know the value of *PACKAGE* at the time the class definition read, compiled, or loaded (which could conceivably be three different values), I do not believe there is any way to retrieve that unless you write code to store it at that time.

Furthermore, it doesn't seem like a meaningful piece of information to have. A package is simply a namespace for symbols, and there's no reason the package that was current at the time the class definition was read, compiled, or loaded should have anything to do with the class itself.

However, if what you really want is for the name of the class x to reside in a package p1, but p2 exports it, you may be interested in adding x to the shadow list of p1 in its defpackage form (or after).

Samuel Edwin Ward
  • 6,526
  • 3
  • 34
  • 62
  • I am building class diagrams and extract slots, methods, and method specializers from classes as well as sub and super classes. It would be nice to group classes according to the package in which they were compiled. The assumption is that each class is defined in a file with appropriate in-package that is chosen by the developer to reflect the package structure of the project. I understand that this might not always be correct but it can still be useful. Assuming that people change the class definition in the exact same file that it was compiled from, the information becomes meaningful. – user1222310 Feb 23 '12 at 01:36
  • I would assume that the package of the class's name reflects the structure of the project. They'll probably be the same most of the time anyway. – Samuel Edwin Ward Feb 23 '12 at 01:57
  • You may be able to define a method on the MOP function `ensure-class` that stows the value of `*package*` somewhere, like a hash table. You'd have to do this before loading the classes you want to know the package of. – Samuel Edwin Ward Feb 23 '12 at 02:04
  • unfortunately the class names don't reflect the structure and i cannot change that now. thanks for the comments. maybe i should also look at how slime jumps to definitions of classes. – user1222310 Feb 23 '12 at 15:53
  • There's a stack overflow question about that, but I can't find it. The short answer is that slime (swank) uses implementation-specific functions to find out where things are defined. – Samuel Edwin Ward Feb 23 '12 at 17:17