develooper Front page | perl.bootstrap | Postings from August 2000

Re: RFC thoughts and guidelines

Thread Previous | Thread Next
From:
Tony Olekshy
Date:
August 16, 2000 00:39
Subject:
Re: RFC thoughts and guidelines
Message ID:
399A448F.DABA4B50@avrasoft.com
On this matter, should something like this be a (meta) RFC?

=head1 TITLE

  Guidelines for Developing Changes for Perl 6 (v0.1).

=head1 ABSTRACT

  - If Perl 5 functionality is not broken (at least for some uses),
    then don't change it unless a critical required core change
    imples the change in functionality.

  - If other canonical functionality can be agreed on, add that in a
    fashion compatible with the existing functionality.

  - If additional functionality can be done in a (core) module, do
    it that way unless you have a *really* good argument otherwise.

  - If you can't do it in a module, try to abstract out the minimal
    changes to Perl (such as the addition of a well-defined hook)
    that will allow it to be done in a module.

  - Make discipline easier to enforce, but don't force any single
    model of discipline, which may not be appropriate to some uses
    of Perl.

=head1 DESCRIPTION

Case Study 1

Even if we agree on a canonical way to handle "error" exceptions
(those generated by some sort of "failure" in the program flow),
our model may not be suitable for other uses the core functionality
provided by eval {}, die, and $@.  It's nice to be able to do those
other kinds of programs in Perl, too.

Case Study 2

When a topic such as Perl's meta-object protocol generates so much
heat, perhaps it's best not to over-constrain available solutions.
Again, even if we largely agree on a new OO way, our model may not
be suitable for other uses the core functionality provided by bless,
the -> operator, and an extensible meta-object protocol.  It's nice
to be able to do those other kinds of programs in Perl, too.

=head1 IMPLEMENTATION

  - Enhance the ability to use a common set of pragmas and modules
    across a group of files, so people can't say all those "uses"
    are an argument against doing things in modules.

  - Enhance performance of modules, so people can't use that as an
    argument against doing things in modules.

  - Add more hooks to Perl and enhance performance of function and
    method calls to allow modules to effectively implement additional
    low-level behaviour.

Yours, &c, Tony Olekshy

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