At 03:53 PM 8/1/00 -0500, Brust, Corwin wrote:
>Could this then also give the programer control over the content of
>error/warning messages produced by Perl at runtime?
That's feasable. It'd be a performance hit, but I can't picture this really
being a performance-critical area... :)
Put together an RFC for it. (Soon!) This is a language topic, but it will
impact internals a touch, and I'd like to get as many of the "impact
internals" things spec'd out as soon as possible. Even if the final form
differs, it's easier to modify a capability than bolt it on after. (cf
perl5 & threads...)
>-----Original Message-----
>From: Steve Simmons [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, August 01, 2000 3:37 PM
>To: Perl6 Language Changes
>Subject: Removing/fixing $[line noise here] variables
>
>
>For deprecation, we should have a %PERL_DEPRECATED{mod}{thing} hash as
>well. `mod' is `CORE', `FORMATS', etc, as above. A value of 0 means the
>function is actually gone, 1 means it's disappearing next major release,
>2 mean next minor, etc. The programmer can control what happens when
>the feature is used by setting a %PERL_DEPRECATED{mod}{warning} value
>to 0 for default, 1 for once, 2 for never, etc, etc.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
