cons-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Packages and cons


From: Gary Oberbrunner
Subject: RE: Packages and cons
Date: Tue, 17 Jul 2001 16:55:47 -0400

Thanks for the info, Jeff.  Actually, at least in cons 2.3.0, all scripts
are evaluated in the 'script' package, but cons deletes all the symbols each
script creates after it evaluates that script (this includes Construct).
This gives the name space cleanliness you mentioned.  It saves the vars so
it can restore them later when doing [perl] builds and AfterBuild functions.

I thought about your #2, but actually since we aren't in the 'cons' package
when reading scripts, won't this still require either an environment, e.g.
$env->get_date(), or else cons::get_date()?

So far the leading contender (for me, YMMV of course) is still modifying all
the Conscripts to have "require 'Cons-subs.pl'".  This isn't really so bad,
I just thought there might be an easy way to avoid it that I was
overlooking.

Thanks,

-- Gary



 > -----Original Message-----
 > From: Jeff Rosenfeld
 >
 > Last I knew, cons evaluated all Conscript files in their own packages
 > (an effort to keep the namespaces clean). Your best bets for extending
 > cons with your new package are:
 >
 > 1. Construct file uses or requires cons-subs. Cons-subs can either
 > create subroutines in its own package (it's unfriendly to define them in
 > main) so that Conscripts can call ConsSubs::get_date.
 >     and/or
 > 2. Your package can define methods in the "cons" package so that
 > Conscripts can invoke them just like other cons methods.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]