Deprecate current PackFile API

Andrew Whitworth wknight8111 at gmail.com
Wed Jan 12 19:57:04 UTC 2011


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
<Christoph.Otto at datasphere.com> wrote:
>> -----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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>


More information about the parrot-dev mailing list