Deprecate current PackFile API
Andrew Whitworth
wknight8111 at gmail.com
Wed Jan 12 15:03:39 UTC 2011
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
More information about the parrot-dev
mailing list