Is there an easy way to find the defining package of a shared variable?
Background: I discovered yesterday that NewPrerequisiteEngine doesn't find prerequisites where the only reference is the use of a shared variable. I was looking at how to fix that problem, and I can't find a good way to find the defining package of the shared variable. I could use PundleAccess>>containingPackageForDataKey:symbol: if I could find the containing environment for the variable binding, but that doesn't seem to be possible either. Am I missing something here? Thanks, Randy -- Randy Coulman [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Randy,
It’s awkward, but you can do so by using the internal search methods of GeneralNameSpace (or is it NameSpaceSearchRules?). The literal binding reference has some context of where it’s used (such as the method mclass), which allows the search to resolve in context. The response from the internal methods is to a block that is given the name space or environment containing the actual binding as well as the binding. Normally, methods like #bindingOrNil throw away the environment, so you’d probably need to implement a method like #bindingEnvironment to return the context. You just resolve the same way but answer the environment, not the binding itself.
Cheers!
From: [hidden email]
[mailto:[hidden email]] On Behalf
Of Randy Coulman
Is there an easy way to find the defining package of a shared variable?
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On Wed, Dec 3, 2008 at 11:15 AM, <[hidden email]> wrote:
I looked at this, and I think I found what you're talking about in GeneralNameSpace. There's the #bindingFor:* methods that seem to do this, but there's a whole bunch of implementers of #bindingFor:modifiers: that would have to be cloned and modified to make this work properly. That seems ugly, somehow. It also looks like those methods don't work for symbols that reference typedefs in an ExternalInterface subclass. I haven't figured out how those get resolved yet. Thanks for the help, though. Randy -- Randy Coulman [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |