[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