[RFC] Branches related to tickets #528 and #631
Jonathan Worthington
jonathan at jnthn.net
Sun May 10 13:23:52 UTC 2009
Vasily Chekalkin wrote:
> Andrew Whitworth wrote:
>>>
>>> Main point - we break API compatibility without proper deprecation
>>> notice.
>>> Previously we used to export all generated C-functions, now we
>>> don't. It
>>> cause problems with language implementations which call those functions
>>> directly. See #651 for lua as very clear explanations.
>>
>> I disagree. We've always suggest that developers use the VTABLE_*
>> macros to access vtable functionality instead of calling the functions
>> directly. People should not be surprised when an internal interface,
>> that we always said not to use directly, disappears.
>
> I tend to disagree with myself as well (just because I was involved in
> those branches). But question is who wins - common sense or
> PARROT_EXPORT?
>
To give some historical context: the reason for having them marked as
PARROT_EXPORT was not that they would be used directly or be part of the
API, but solely because they had to be exported for dynpmcs to compile
properly under certain compilers (e.g. MS VC++, which for better or
worse lacks a "just export everything non-static" option).
I think every embedding or extending doc has pointed to using VTABLE_*
forms, and for good reason - not doing so is a good way to bust
polymorphism and break subclassing. So while we might catch some folks
out because these symbols just happened to be exported, I count it very
much as an internals change rather than an interface change.
Jonathan
More information about the parrot-dev
mailing list