Deprecate current PackFile API

[Christoph Otto]

> -----Original Message-----
> From: parrot-dev-bounces at lists.parrot.org [mailto:parrot-dev-
> bounces at lists.parrot.org] On Behalf Of Andrew Whitworth
> Sent: Wednesday, January 12, 2011 07:04
> To: parrot-dev at lists.parrot.org
> Subject: Deprecate current PackFile API
> 
> I should have mentioned this yesterday at #ps. With all the changes we
> have planned, I think we want to insert a deprecation notice for the
> current Packfile API (src/packfile/api.c, mostly) before the 3.0
> release. Our goal with that subsystem is to create a new API for the
> system, and reimplement many of it's internals to be cleaner and
> better.
> 
> Most users won't use any of these functions. For instance, there are
> some packfile-related functions in src/embed.c which users would be
> using, and which are already covered by a separate deprecation notice
> for that file. Extenders likewise probably have little use for these
> functions.
> 
> If people think that the packfile functions (PackFile_*, but also
> Parrot_pf_*, primarily) are part of our public API, we should put in a
> deprecation notice to cover future changes *now*. If people don't
> consider this subsystem to be part of our public API, then we probably
> don't need the notice. I would rather be safe here, because we have
> lots of changes to this subsystem that we would like to make in the
> coming months and I would hate to be slowed down or caught in a
> "gotcha" kind of problem.
> 
> If anybody is using functions from src/packfile/api.c directly, let me
> know. If anybody has an opinion on this matter one way or the other,
> please also let me know. I'll add in a deprecation notice later
> tonight or tomorrow if there aren't any objections.
> 
> Thanks,
> 
> --Andrew Whitworth

I was sad to find out that our packfiles are indeed part of the API to some 
extent, so they will need a deprecation cycle.  Thanks to bacek's work, we 
now have the possibility of deprecating all packfile-related functions and 
requiring that any manipulation by users go through the PMC interface.  I 
don't know if the PMCs are completely stable yet (and it seems unlikely given 
how recently they were updated), but once they're ready I'd prefer we 
deprecate the externally-facing parts of the C API entirely in favor of the 
PMCs.

Christoph