is there any way to import constants from other modules without
specifying scope everytime?
such like this:
module A;
use constant { PI => 3.14, VER => 1.1 }
...
####
module B;
my $var = A::PI; # this way is fine when A is 'short' or rare
#### imagination
module C;
use constant tag { PI => 3.14, VER => 1.1 }
...
####
module D;
use constant C::tag;
my $var = PI; # forgive my laziness
is it a good idea to have header files and include pragma?
(sometimes, a big module file is also a headache. having this
feature, we could split it up.)
song10
_______________________________________________________________________
Yahoo!奇摩電子信箱
免費容量250MB,信件在多也不怕
http://tw.promo.yahoo.com/mail_new/index.html
I'm assuming that you want to write all those modules in one file
without reimporting into every package. That's the default, since
use will import into the lexical scope by default, so it will span
all the packages. See
http://dev.perl.org/perl6/synopsis/S11.html#Importation
for more on that.
On the other hand, your comment below leads me to believe that you
might be asking for a way to do the same importation in separate files.
It seems to me that you're asking for a "policy" module that imports
on behalf of its user. I've said we will have policy modules, but
we haven't defined a syntax for that yet. One way to do it would be
for it to return a string to be evaluated as part of the compilation
of the user's scope. That would be very powerful, but perhaps too
powerful to be the default way of doing things. So, much like the
distinction between text macros and "hygienic" macros, I'd like to
see a way of providing a generic chunk of code to the using context
either as raw text or as a precompiled hygienic code that has to
be linked in as a form of generic code. We'd encourage people to
use the templating approach over the textual approach because it's
guaranteed to be syntactically correct, and makes it easier to keep
track of where the code came from for debugging purposes.
We already have to do something much like this to compose roles
into classes. Roles are another form of generics.
: is it a good idea to have header files and include pragma?
: (sometimes, a big module file is also a headache. having this
: feature, we could split it up.)
When I see what a mess C and C++ get into with textual inclusion,
I am hesitant to make the same mistake in Perl. I think we'll make
it possible, but we'll try to make it easier to write hygienic policy
modules instead.
Larry