On Wed, 4 Nov 2009, Gerard Goossen wrote:

>  As access to some part of the internals of core is desired (as for
>  example shown by the existance of Data-Alias). But we don't want this
>  to lock the whole core because some module is doing some stuff very
>  deep in the internals.
>  
>  To solve this I would like to make a major version specific API.
>  
>  Attached patch adds the requirement of having "PERL_CORE_5_<version>"
>  defined when PERL_CORE is defined.

I note that you (deliberately) omitted the subversion, so that you have 
something like PERL_CORE_5_12 instead of PERL_CORE_5_12_1 .  I think 
that's a bad idea since it seems to be making a promise that no private, 
internal parts of the core can be changed in a non-compatible way even in 
a maintenance release.  While that's probably often true, I don't think it 
should be policy to require it.

>  The idea is that modules are allowed to use the internals of the perl
>  core (at their own risk of course) by defining PERL_CORE and
>  PERL_CORE_5_<version> (multiple versions can be supported by a module
>  by having multiple PERL_CORE_<version> definitions)

>  This means we can allow modules to do all kinds of interesting stuff, 
>  because we have an interface for that, but that this interface is
>  version specific, allowing the core to be further developed.

Modules can, of course, already do this by defining PERL_CORE.  Since 
PERL_REVISION, PERL_VERSION, and PERL_SUBVERSION are already available, 
module authors can (and do) make those things version-specific.

>  With this change, normal release goes like this:
>  - First release candicate/beta is made.
>  - Modules doing ugly stuff like Abra::Cadabra, break with a compile error.
>  - Author of Abra::Cadabra makes changes to the module for changes
>    internal to perl, and adds the "#define PERL_CORE_5_<version>",
>    makes release. (Changes are the changes to the module were already
>    made as to work with bleadperl and only adding the define would be
>    enough).

Module authors can already do this by using the various PERL_* #defines 
that already exist in patchlevel.h to only allow compilation on versions 
known to work.  Whether or not they choose to do so, of course, is a 
different matter.

>  Of course the idea is not to break these modules, but just to enforce
>  that the author checks that nothing of the internals have changed in
>  such a way as to break the module. It might be that nothing used by
>  the module has changed and that just adding "#define
>  PERL_CORE_5_<version>" is enough, or some superficial changes in the
>  use of the interface might be required, or it might be that there
>  where significant changes and the core and that significant changes
>  are required.

If the module author is careful and carefully reviews the changes in the 
perl internals to check whether they impact the module, I could see this 
being a benefit.  If, on the other hand, the module author merely adds 
#define PERL_CORE_<version>  and runs the test suite to "see if anything 
breaks", then the extra hoops haven't really done any good and have simply 
added additional makework.

Of course, the module author can already enforce the breakage by using the 
existing #defines in patchlevel.h.


>  Summarizing:
>  - The core developers promise to keep the core the same within each
>    major version.

No, I think that's not a good idea.

>  - Module authors defining PERL_CORE promise to make adjustment with
>    each major perl release.

I think they may have to make them with each major or minor release.

>  - Together we live happily ever after.

Indeed, that's a noble goal!  Another way to work towards that goal might 
be to work to develop an API that provides whatever was missing and 
required the PERL_CORE stuff in the first place.

-- 
    Andy Dougherty		doughera@lafayette.edu