On Mon, Feb 16, 2004 at 11:50:42AM +, Simon Cozens wrote:
This is why I tend to do something like this in Makefile.PL:
print WARNING: This new major release is incompatible with previous\n;
print releases. Please check any code which uses this module.\n;
print Press enter
There is an ugly problem with the use of caller() in the solution below.
Functions used in one package can be passed by reference to another package.
The behavior of the function will be defined by the context in which the
function is invoked, not be the context in which it is imported. Subtle
Hi,
David [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
There's not really much a module author can to do help a user like that.
yes there is, it's the custom VERSION subroutine. Your legacy program
dies with the error message
until it is edited, after the module upgrade.
Vagn Johansen [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
How do you avoid breaking old programs when the interface changes?
You don't. IMHO it's the users responsibility to check for what version they
are using not the module author. With Module Build you can ask for a
specific
[EMAIL PROTECTED] (Khemir Nadim) writes:
Vagn Johansen [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
How do you avoid breaking old programs when the interface changes?
You don't. IMHO it's the users responsibility to check for what version they
are using not the module author.
David Nicol on 15 Feb 2004 18:31:25 -0600 writes:
On Fri, 2004-02-13 at 00:45, David Manura wrote:
[ the interface will change! ]
I hope you are planning on adding a VERSION subroutine that will not
accept requests for old, incompatible versions, while accepting requests
for all later
Simon Cozens wrote:
[EMAIL PROTECTED] (Khemir Nadim) writes:
When I get the message above, I'll hit the return key faster than light
There's not really much a module author can to do help a user like that.
yes there is, it's the custom VERSION subroutine. Your legacy program
dies with
Vagn Johansen wrote:
How are interface changes handled on CPAN?
They're not. I'm trying to promote a pradigm of including a VERSION
subroutine that
will croak (or at least die) when you ask for a non-forwards-compat.
version.
In theory, you change the name when you change the itnerface,
David Manura wrote:
As the current maintainer of Text::Balanced,
And *thank-you* for taking on that role, David! :-)
(2) extract_multiple will recognize only the empty list and (undef, ...)
return values from extractor functions as match failures. This is what
the POD currently states, but
As the current maintainer of Text::Balanced, I'm proposing for public review the
following changes (or clarifications) to the external interface of
Text::Balanced to be effective in version 1.96:
(1) All extractors will return (undef, $$textref) on failure in list context.
Although a subtle
10 matches
Mail list logo
