Re^3: evil code of the day: global stricture control

I'm guessing the chances you can get a perl process that has no Exporter.pm are zero to nil. I don't think your avoidance of Carp on the principle of also avoiding Exporter is sound.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Comment on Re^3: evil code of the day: global stricture control

Replies are listed 'Best First'.
Re^4: evil code of the day: global stricture control by vkon (Curate) on Aug 02, 2007 at 15:10 UTC
yes, Exporter in unavoidable. But, let me repeat my point, I have some bootstrap technique, and during first stage of bootstrapping no Exporter and Carp are available, so I must strip them out from Tcl.pm, which aims bootstrap.	[reply]
Re^5: evil code of the day: global stricture control by diotalevi (Canon) on Aug 02, 2007 at 16:06 UTC
Er, what? You're bootstrapping a build of perl then? Any perl that's been built is going to have those already and in fact ... if you can run perl code you can run either of those already. I don't get it. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^6: evil code of the day: global stricture control by vkon (Curate) on Aug 02, 2007 at 20:53 UTC
My applications designed to run even if perl not present, much like PAR. Unlike PAR, it do not create temporaries, it unzips Perl modules on-the-fly. My bootstraping sequence starts somewhere, where Carp.pm is not seen, but then Carp.pm becomes seen, when bootstrap sequence reaches certain point. Sorry if explanations are not clear, I'm not native English.	[reply]