[dev] [commits] Horde branch master updated. 0badb203589d36e1c158d97e03748b2faa834e0b

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> commit c1e2d8dd37c6c44be05e2636a6fe67520ca63d99
>> Author: Jan Schneider <jan at horde.org>
>> Date:   Wed Jan 28 15:37:31 2015 +0100
>>
>>    Could as well implement those methods directly in Socket\Client.
>>
>> framework/ManageSieve/lib/Horde/ManageSieve.php            |    7 +-
>> framework/ManageSieve/lib/Horde/ManageSieve/Connection.php |  112 ---------
>> framework/ManageSieve/package.xml                          |    6 +-
>> framework/Socket_Client/doc/Horde/Socket/Client/UPGRADING  |   12 +
>> framework/Socket_Client/lib/Horde/Socket/Client.php        |  150  
>> +++++++++--
>> framework/Socket_Client/package.xml                        |   18 +-
>> 6 files changed, 150 insertions(+), 155 deletions(-)
>> delete mode 100644  
>> framework/ManageSieve/lib/Horde/ManageSieve/Connection.php
>>
>> http://github.com/horde/horde/commit/c1e2d8dd37c6c44be05e2636a6fe67520ca63d99
>
> Unfortunately, this breaks Horde_Imap_Client.  It has declared a  
> read() method, without an argument, since Socket_Client version  
> 1.0.0.  The base Socket_Client class now declares read() with a  
> single $size argument.  Declarations don't match and PHP complains  
> (see the Horde_Mail_Autoconfig unit tests).
>
> Not really sure how to fix this.  It can be argued that this should  
> be fixed in Horde_Imap_Client to no longer declare a read() method,  
> but that would then mean that EVERY version of Horde_Imap_Client  
> before the to-be-released version in the future is irrevocably  
> broken if using PEAR to install, since it will install using the  
> latest version of Socket_Client.
>
> Another solution would be to use func_get_args() in the base call to  
> parse $size.  Although this isn't preferable because 1)  
> func_get_args() is ugly and 2) this is hacky in that the producer is  
> required to change based on the use-case of a consumer.

We could make this Horde_Socket_Client 2.0.0. Horde_ManageSieve could  
require this version, as well as the fixed Horde_Imap_Client and  
Horde_Smtp. The unfixed versions exclude 2.0.0, so there cannot be  
accidental upgrades.

> We can always establish some sort of naming convention going forward  
> to eliminate this kind of conflict in extended classes, but that is  
> just adding unneeded coding standards complexity for a use case that  
> rarely if ever happens.

Agreed, this is indeed too rare to worry about.

-- 
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject