develooper Front page | perl.perl5.porters | Postings from September 2010

Re: [RFC] Exposing PL_dirty to perl space

Thread Previous | Thread Next
From:
Florian Ragwitz
Date:
September 27, 2010 22:34
Subject:
Re: [RFC] Exposing PL_dirty to perl space
Message ID:
87eicebffm.fsf@tardis.home.perldition.org
"Jan Dubois" <jand@activestate.com> writes:
> On Mon, 27 Sep 2010, Florian Ragwitz wrote:
>> So here comes the patch. I'd be very interested in both comments on
>> the patch and possible other ideas for exposing this information.
>
> I like the global much better than an additional argument to DESTROY.
> In some ways I would have expected to find this information in $^S,
> but the way it is already defined it doesn't have a good extension
> mechanism.

I don't think this fits well into $^S. At least I have always thought of
it as "what will happen if i throw an exception now?". But also adding
more things to $^S seems pretty hard, as you pointed out.

> So I'm wondering if it would be better to have a more generic
> ${^STATE} that could also indicate other states beyond global
> destruction, e.g. inside BEGIN/INIT/CHECK/END blocks, or running
> during sitecustomize.pl etc.  At the application level you can always
> pass this information yourself, but an interpreter provided state
> would help generic CPAN modules.

Good point. I hadn't thought of that.

> However, I've never needed these other states so far, so maybe it is
> overkill.

I haven't ever needed any of that either. It also doesn't seem entirely
clear to me how this information would look like. One module's run-time
can happen during another module's compile-time, etc.

I don't think this information is worth having around.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About