Okay, so let's put in the deprecation notice for these functions now, to give users the heads-up that they will be changing in some way at some time.
--Andrew Whitworth On Wed, Jan 12, 2011 at 2:50 PM, Christoph Otto <[email protected]> wrote: >> -----Original Message----- >> From: [email protected] [mailto:parrot-dev- >> [email protected]] On Behalf Of Andrew Whitworth >> Sent: Wednesday, January 12, 2011 07:04 >> To: [email protected] >> 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 > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
