At 08:11 PM 8/23/2001 -0400, Robert Spier wrote:
>Just some brief comments... $0.02 or some such. :)
> > The top-level structure of the Perl source tarball should be as
> > follows:
> >
> > /README, etc a few top-level documents
> > /doc/ Assorted miscellaneous documentation
> > /pdd/ The current PDDs
> > /perl/ The source code for Perl itself
> > /perl/os/foo/ OS-specific source code for operating system foo
>
>Why is perl a second class citzen in the Perl source tarball? Why not
>just /src/ ?
It ought to be /src/parrot for the interpreter source, with a /src/perl
subdirectory for the perl-specific bits like the parser. Maybe the variable
code too, though I'm not sure if the base perl scalar/hash/array/list
variables will be considered plain base parrot types. Probably will,
thinking of it.
>/perl/ is somewhat confusing as well, sounds like where perl code should live.
>
>
> > /lib/ perl modules ready for installation
> > /ext/ perl modules that need compiling
>
>Do these really need to be seperate? Would it simplify things to have them
>together? If it's ready for installation, you just don't do anything to it.
I think we should go for one tree. Probably under /src/perl or /perl.
> > should be used over a bare char * whenever possible. Ideally there
> > should
> > be no char * in the source anywhere, and no use of C's standard string
> > library.
>
>Isn't this a little overzealous? I know there are differences between
>implementations of the standard string library, but there _is_ a standard
>that should be mostly safe to use.
No. Delimited buffers (and hence char *) are unsafe. I don't want char *
and the C string library used anywhere except in interfaces to external
libraries. I'd as soon not use C's string library anywhere at all, and
instead force folks to use library routines that require (and enforce)
buffer lengths and such.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
