facades, use_ok, and lexical export

2006-01-09 Thread Gaal Yahas
Consider use_ok from the test system. Essentially, it should be require $module; $module.import; pass load $module; in its caller's context. But now that exportation is lexical, how can use_ok be implemented? It must divert the symbols installed by import and have them installed in the caller

Re: facades, use_ok, and lexical export

2006-01-09 Thread Yuval Kogman
What we need to do is find a way to do this at compile time. One way is to make use_ok a macro. The whole thing with linkage in Perl 6 is that it's supposed to happen at compile time so that things are overall saner, but that it can happen at runtime if we really really mean it. use_ok as a

Re: facades, use_ok, and lexical export

2006-01-09 Thread Luke Palmer
On 1/9/06, Gaal Yahas [EMAIL PROTECTED] wrote: sub use_ok($module) { eval package {caller.package}; require etc.; } I'd like to see a nice interface to scopes in general. That is, we would have a scope object which would provide access to all the lexical scopes and the package

S12: Possible contradiction in responsibilities of Class Object

2006-01-09 Thread Stevan Little
Hello all, I have been reading the recently updated Synopsis 12, and a few things jumped out at me. In the Classes section, classes are described like this: Classes are primarily for instance management, not code reuse. Later in the same section the following is stated: Every

Construction and Initialization of repr types other than P6opaque

2006-01-09 Thread Stevan Little
Hello again, In Pugs, we are currently trying to figure out how classes are initialized with $repr types other than P6opaque. My interpretation of S12 is that P6opaque types are initialized as follows (by default): new is called with named arguments, it then calls bless passing in