Re: [commits] Horde branch master updated. 0badb203589d36e1c158d97e03748b2faa834e0b
Jan Schneider <[email protected]>
| Newsgroups | gmane.comp.horde.devel |
|---|---|
| Message-ID | <[email protected]> |
Zitat von Michael M Slusarz <[email protected]>: > 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 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 -- dev mailing list Frequently Asked Questions: http://wiki.horde.org/FAQ To unsubscribe, mail: [email protected]