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

[Michael M Slusarz]

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 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.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]