On Thursday, Sep 19, 2002, at 03:33 US/Pacific, Cricker wrote:
[..]
> Thank you very much for your clear explanation. I am indeed in this
> for the
> long haul, so will accept your advice to spend the extra time now and
> write
> modules. I had actually settled on the last approach you mention, but
> now I
> see its limitations.
in the long run this will save you time.
what many folks do not always 'catch' when newer versions
of perl come out - not all of the 'modifications' are to the
'c' code that builds a 'perl' as an executable binary image -
some of them are in the 'supporting code' that has become a
part of the 'default modules'....
In the same manner your 'core code' may not need to be 'upgraded'
to fix a 'feature' - if it is something in one of your supporting
modules.... so being able to release updates to your modules makes
the process of not having to fix all of the 'supporting apps' that
much simpler...
> If I may summarize -- and please correct me if this is wrong -- there
> is
> indeed no way to textually include one file inside another, like
> #include in
> C. The text file is the compilation (lexical) unit, and the only way
> to
> import lexical symbols is via the module (package) mechanism.
[..]
I think we sorta agree here. I will presume that you are not
asking for the sort of 'c pre-processor games' that at times are played
where one is going for
$(CPP) $(CPP_FLAGS) -o myApp.plx silly.c
in which a 'c style' set of #include and #define directives
are stacked up in silly.c and when the preprocessed "makes"
the big file of perl code which can be executed....
WARNING: the following requires a bit of knowledge about
the difference between runtime libraries a la 'libFoo.so'
vice the compile time libraries a la 'libFoo.a'....
If you shift your vision of what is going on here from the
'statically linked reference' to the 'dynamically linked references'
that are 'resolved at run time' - it may be easier to view the
use MyDom::MyClass qw/:list_oh_funks/;
as being similar to the sort of
#include "That_dyna_lib.h"
that you would use when building an executable that has a
dependency of libThat_dyna_lib.so being in the LD_LIBRARY_PATH
and/or that at build time you built with the
-R /path/to/our/dyna_libs
flag that will be passed through to ld so that the ld.so will
seek to resolve at run time all open references....
As such, you are not really trying to do the 'import the objects'
from libThat_lib.a at 'compile time' which were referenced by
#include <That_lib.h>
in your code....
It helps to see the game in this perspective - since remeber that
the first thing out the shoot that
#!/path/to/perl -w
does is 'compile' the 'perl text file' and do all of the resolution
of open 'symbols'.... an illustration
#!/usr/bin/perl -w
use strict;
use Data::Dumper;
my @list = qw/a b c d e/;
print Dumper \@list ;
will 'work' because 'Dumper' is "resolved" at Runtime as coming
from Data::Dumper - cf perldoc Data::Dumper.... but we all make
the OOPSIE of
#!/usr/bin/perl -w
use strict;
my @list = qw/a b c d e/;
print Dumper \@list ;
which will generate error messages of the form:
#File "untitled text"; Line 8: Name "main::Dumper" used only once:
possible typo
#File "untitled text"; Line 8: Filehandle main::Dumper never opened
since the perl compiler sees that Dumper is in the place where a
filehandle
should have been, but was never opened.... also it views Dumper as a
variable
in the main:: name space.... In short - we did not tell perl that we
wanted
the token Dumper to be resolved as a 'symbol' that references code that
is
found in 'the dynamic library' Data::Dumper.....
As such the 'use' directive is like the 'include directive' - as well
as sets what are in essence 'compile time flags' as well as 'run time'
flags....
Does that help articulate a bit of the difference between one way
of viewing the
#include
vice
use
pragma's????
ciao
drieux
http://www.wetware.com/drieux/pbl/
--------------
This space left intentionally blank.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
