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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
