Re: [commits] Horde branch master updated. 0badb203589d36e1c158d97e03748b2faa834e0b

Michael M Slusarz <[email protected]>
Newsgroups gmane.comp.horde.devel
Message-ID <20150128145818.Horde.Mlzyrm6_3OqKiYvTwhqT4Q7@bigworm.curecanti.org>
Quoting Jan Schneider <[email protected]>:

> commit c1e2d8dd37c6c44be05e2636a6fe67520ca63d99
> Author: Jan Schneider <[email protected]>
> 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 [[email protected]]

-- 
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.