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
address@hidden
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 :
address@hidden
[mailto:address@hidden]
De la part de Laurent Destailleur (aka Eldy)
Envoyé : mercredi 19 août 2015 20:51
À : Posts about Dolibarr ERP & CRM development
and coding <address@hidden>
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 <address@hidden>:
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</small>
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
|