Yes, that's one of the reasons I want executing code to have access to
it's own package. Once you have that, you can do things such as
dyamically add other packages to your lookup scope, perform dynamic
class resolution, etc. At lot of these functions will be particularly
useful from the native A
Rick,
You know I did a little investigation, using a sort of reflexion and
discovered that. It is quite cool.
src = .array~new
src[1] = "::routine speak public"
src[2] = "use strict arg w = 'Hello World'"
src[3] = "say w"
src[4] = "return 0"
obj = .Package~new("test", src)
itr =
Realized I didn't answer all of your questions. The other new class
is the Routine class, which decouples Routines from Methods.
Previously, a ::ROUTINE directive created a Method objectnow it
creates a Routine object. You could also have generated the parser
errors using a Routine object in
It should still be available in the condition traceback information,
just like you're doing with assertion failures.
Rick
On Tue, Jul 1, 2008 at 4:40 PM, Mark Miesfeld <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 11:29 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
>
>> I was looking at what
On Tue, Jul 1, 2008 at 11:29 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> I was looking at what you've done for processing syntax errors in the
> CONSTANT directive test group, and I have some suggestions that might
> make these types of tests easier to manage. To start with, you can
> completel
Mark,
I was looking at what you've done for processing syntax errors in the
CONSTANT directive test group, and I have some suggestions that might
make these types of tests easier to manage. To start with, you can
completely eliminate the need to write this to a file by using the new
package class
