Hello,
That already the case in most of the times, deprecated
function/method put warning log that said Method will be deprecated
(good exemple is hook resprint feature with multicompany, in 3.6 it was
a warning, in 3.7 it is an error into log (but still works)). The
setEventMessage produced a warning log message but this line have been
commented because this function is used by setEventMessages :
function setEventMessage($mesgs, $style='mesgs')
{
//dol_syslog(__FUNCTION__ . " is deprecated", LOG_WARNING);
This is not deprecated, it is used by setEventMessages function
In object world we should said private method, but is is a function not
a method.
My point wasn't to open discution about retrocompatibility.
To my mind, even if I can be upset when my modules didn't work anymore
on new dolibarr version cause of change into core, I accept it and take
time to upgrade my module, that why we sell them, not only to pay dutty
on them but to have fund to upgrade them. In other case, put should give
for free on Dolistore.
In most of case, change in dolibarr core goal is to cleanup bad code or
make it better and I can't imagine that you can agreed that.
On the other hands, an exemple is canvas feature, it was broken, and
Christophe, you discover it and complain on this mailling list, and it
was fixed, thank to you I can use them now. This kind of stuff is always
tricky because only module use it, and see a regression is not easy with
standard units test. Only module developpers can be aware of that.
Change table column name like fk_soc to fk_thirdparty is a very good
idea, it will break a lot's of stuff but allow automation stuff like
thirdparty fusion feature (in 3.8), I prefer to review my code in this
case rather than open SQL manager to check the column name in each table
because on time it's id another rowid, or fk_sod, or socid, or
fk_thirdparty... As Laurent said during the devcamp : "step by step, no
big bang", but after 2 years of deprecated function/method it seems to
be enought to take time to upgrade modules.
My two cents.
Florian Henry
+33 6 03 76 48 07
[email protected]
http://www.open-concept.pro
Twitter : @_Open_Concept_
Google+ : https://www.google.com/+Open-conceptPro
Le 19/08/2015 22:41, Charles Benke a écrit :
>
>
>
> Propose to add a specific log trace for use of retrocompatibility function
>
>
>
> Bien cordialement,
>
> Charlie Benke
>
>
>
> *De :*[email protected]
> [mailto:[email protected]] *De la
> part de* Laurent Destailleur (aka Eldy)
> *Envoyé :* mercredi 19 août 2015 20:51
> *À :* Posts about Dolibarr ERP & CRM development and coding
> <[email protected]>
> *Objet :* Re: [Dolibarr-dev] Question about sed RegExp for
> setEventMessages
>
>
>
> That's the way it is now.
>
>
>
> But we can't maintaint all retrocompatibility functions for ever. If
> we did that, dolibarr code should be currently 2 or 3 times larger in
> code line than it is now making it not possible to be enhanced. That's
> why retrocompatibility for very used function is kept only during 1 or
> 2 year only and why we will remove this deprecated function one day.
>
>
>
>
>
>
>
> 2015-08-19 17:19 GMT+02:00 Christophe Battarel
> <[email protected]
> <mailto:[email protected]>>:
>
> Best answer: retrocompatibility !!! Lets's have a setEventMessage
> function that calls the new one !
>
> /J'ai l'impression de me répéter et de pisser dans un violon
> parfois.../
>
> Le 19/08/2015 16:47, Florian HENRY a écrit :
>
> Hello all,
>
>
>
> Do you have in your basket a shell script (I imagine with sed and
>
> regexp) or any tools that can update externals modules (to be ready
> when
>
> setEventMessage will be remove to setEventMessages) ?
>
>
>
> The game is change
>
> setEventMessage(aaa,bbb);
>
> to
>
> SetEventMessages(aaaa,null,bbbb);
>
>
>
> Regards
>
>
>
>
>
> --
>
> <small><i>Christophe Battarel<br/>
>
> Responsable technique Altairis</i><br/>
>
> +33 (0)9 52 71 70 96 <tel:%2B33%20%280%299%2052%2071%2070%2096></small>
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> [email protected] <mailto:[email protected]>
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
>
>
>
> --
>
> EMail: [email protected] <mailto:[email protected]>
>
> Web: http://www.destailleur.fr
>
> ------------------------------------------------------------------------------------
>
> Google+: https://plus.google.com/+LaurentDestailleur/
> Facebook: https://www.facebook.com/Destailleur.Laurent
>
> Twitter: http://www.twitter.com/eldy10
>
> ------------------------------------------------------------------------------------
>
> * Dolibarr (Project leader): http://www.dolibarr.org (make a donation
> for Dolibarr project via Paypal: [email protected]
> <mailto:[email protected]>)
>
> * AWStats (Author) : http://awstats.sourceforge.net (make a donation
> for AWStats project via Paypal: [email protected]
> <mailto:[email protected]>)
>
> * AWBot (Author) : http://awbot.sourceforge.net
>
> * CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
>
>
>
>
>
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
