Simon Cozens:
# People were complaining about bloat already? Well, I'm not a
# great believer in
# taking 1800 lines to do what you can do more clearly in 700;
# nor taking 43
# functions, many of which are completely unused, to do the
# work of 14. This
# refactoring does not attempt to disguise the fact that C is not
# object-oriented Perl.
#
# The attached patch reduces packfile.c to a manageable size,
# removes some
# memory allocation bugs, makes the string type and encoding
# support correct,
# and also makes it considerably easier to read and understand.
# I still think
# that 700 is too many for such a simple job, but we'll have to
# wait until after
# the bytecode PDD is finished to see how many more we can
# lose. But still,
# given that packfile.c was second only in length to the core
# ops files and
# three times the size of anything else, I think this isn't bad
# for a first
# trim.
#
# Yes, this removes some of the functionality for creating
# packfiles, which
# we don't currently use, but I've moved those to another file
# so that they
# can be XS-wrapped and used by the assembler as was the plan
# all along.
What about the C-level compiler? Will this still be included in the
core?
# It also removes the functions for dumping packfiles; I've
# already expressed
# my opinions of pdump, and might even be happy with just a
# Perl disassembler.
# But I've moved the dump functions into a separate file as
# well just in case.
I will not cry to see these go.
# In other news, "struct PackFile" is an amazingly misleading
# name, and I'd
# welcome suggestions for a replacement. When you have a full
# struct PackFile,
# what you have is neither packed, nor a file.
"BytecodePack" or "CodePack"? ("Pack" as in "package", not as in
"packed".)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
