On Thu, Feb 22, 2001 at 09:11:03PM +0000, Simon Cozens wrote:
> On Thu, Feb 22, 2001 at 12:39:25PM -0800, Edward Peschko wrote:
> > The current RFCs need work.
> 
> Be assured that they're getting lots of top-quality work.
> 
> > There are new RFCs that could be written. Its totally counter-productive to
> 
> ... ship a specification to a designer, and then keep adding more and more new
> requests to change it. Don't you just *hate* that when people change the
> specifications while you're half way through writing a project? Don't do it to
> Perl's design.

No I actually don't hate it. Because if I can fit in new features based on my
original design, it gives me validation that I'm going down the right path.

And I don't think that the first round of perl6 will contain all of its 
ultimate features - you work outward from a set of central principles.  If you 
see a cool feature that somehow modifies your original design, you make the 
choice whether or not its worth the effort to fit that feature in.

Here for example was something that was totally missed in the RFCs and *should*
be spec'd out (I believe):

perl should have a mechanism for loading libraries like a '.so' ie, you should
be able to install a library like:

Data/Dumper.pm.1.2.4


and say

'use Data::Dumper qw(1.2.4);'

or 

'use Data::Dumper qw(last);'

And of course it should be tied into CPAN.

Now the syntax is suspect, but it allows for large applications/APIs to specify 
which version of a library it needs. And it guards them against breakages if 
somebody decides to change the API that *you* are depending on.

Now of course this is debatable, but I think it should be written down, and 
argued about. If its found to be a good RFC, it makes it as the starting point 
of a PDD. If it isn't, its labeled 'retracted' and its a guidepost to not 
starting the same damn conversation over and over again. 

Like I said, you could shoehorn this into PDD, but why?

Ed

Reply via email to