Nick Ing-Simmons wrote:
>
> SilvioCVdeAlmeida <[EMAIL PROTECTED]> writes:
> >
> >Hello,
> >I have some obscure points around C function eval_pv.
> >
>
> I don't understand the question yet ...
>
> >
> >Specifically, I don't understand why eval_pv cannot
> >access a pre-defined main::subroutine as it does for
> >a packaged one, eg. pack::subroutine.
> >
> >In other words, why distinct eval_pv calls don't
> >share the main scope, but do share package scope?
> >
>
> main:: _is_ a package, and it is shared exactly the
> same as all other packages. So I don't think the
> problem is what you think it is...
>
> Are you calling sub as main::subroutine() or as
> subroutine() ?
>
> XS code's "current package" is the current package
> of the calling perl code, NOT the package in which
> XS resides. (This is becuase current package is a
> per Current Op thing and XS doesn't have OPs so last
> executed perl statement's one gets used.)
Thatīs it! My project has a scheme based on the example of a Persistent
Interpreter from perlembed.pod, where each script file defines its own
unique package name, for the purpose of the cache system. So, I always
call a subroutine from inside a package.
What OP above means?
> Another thing is that XS code has no "lexical scope"
> so my/our declarations can't be seen.
I suppose the concept here is the same as from the current package you
described above.
> >Perl docs tells nothing more than almost nothing
> >about "eval_pv", so I would greatly appreciate some
> >link/info about it.
> >
>
> Essentially it is "as if" the code that called your
> XS had done
>
> eval "Some string";
Indeed,
sub pmain { "PackageMAIN\n" }
package Pack;
sub ppack { "PackagePACK\n" }
eval "print 1, pmain()";
eval "print 2, ppack()";
package main;
eval "print 3, pmain()";
eval "print 4, ppack()";
prints:
2PackagePACK
3PackageMAIN
Thank you, Nick.
Silvio
