libdate-calc-perl (6.3-1) unstable; urgency=low Since version 6.2, Date::Calc only contains a pure Perl implementation. The XS-accelerated implementation was separated into its own package, libdate-calc-xs-perl, and will automatically be used when installed. -- Florian Schlichting <fschlich@zedat.fu-berlin.de> Mon, 12 Sep 2011 21:44:37 +0200 libdate-calc-perl (6.0-1) unstable; urgency=low In version 6.0 of Date::Calc the interface to DateCalc.c has changed. Thus check for details `/usr/share/doc/lidate-calc-perl/README.txt.gz'. Backward compatibility: ----------------------- Module "Date::Calc" should be 100% backward compatible, meaning that no changes to existing code using reasonably recent versions of "Date::Calc" should be necessary (consult the changes history in file "CHANGES.txt" for possible incompatible changes between versions). Note that when you pass an invalid language number to any of the affected functions, you will get the previous behaviour, in which a global variable (set by the function "Language()") determines the language to be used. Note again that this new language parameter in the affected functions is optional; omitting it gives you the previous behaviour with the global variable as well (this is where the compatibility with existing code stems from). When using the C library "DateCalc.c", where omitting a parameter is not an option, passing a zero for the language is therefore the recommended way to guarantee backward compatibility and to keep changes to existing code to a minimum. Modules "Date::Calc::Object" and "Date::Calendar::Year" should be backward compatible as well (modules "Date::Calendar" and "Date::Calendar::Profiles" have not been changed). However, because the global variable (the one set by the function "Language()") is not set temporarily anymore by language-dependent methods and overridden operators (and restituted at the end, very similar to the "local" operator in Perl), you might perceive differences if your existing code relied on these implementation details (some test cases in the test suite of this package tested this and had therefore to be changed). The advantage to be gained by all this is that now, all modules in this package should be thread-safe and safe to be used by several concurrently executed modules, as long as you do not set the language using the global function "Language()" or the CLASS method "language()" (and as long as you do not use any other global setting, for that matter), but EXCLUSIVELY by passing the language parameter to all functions individually and by using the OBJECT method "language()". By exclusively using local settings, you are also making your code invulnerable against other, concurrent modules which still use global settings. -- Salvatore Bonaccorso <salvatore.bonaccorso@gmail.com> Thu, 08 Oct 2009 22:28:18 +0200
Generated by dwww version 1.15 on Sun Jun 30 23:55:08 CEST 2024.