[dev] [commits] Horde branch master updated. 88679069d1c1d9759b468e93356514aa86488796

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> commit ea32d50494dcadacd5173f8059f6f49f8b3dfbf1
>> Author: Jan Schneider <jan at horde.org>
>> Date:   Fri Feb 3 17:36:53 2017 +0100
>>
>>    Make the $value a string-only property again.
>>
>>    It's a BC break that this might sometimes be a stream now.  
>> Instead make $value a setter/getter and add $stream property too.  
>> Convert between these two on the fly.
>>    Also make Horde_Db_Value_Text extend Horde_Db_Value_Binary  
>> because they share most of the code. This requires to change some  
>> class tests though, because "instanceof Horde_Db_Value_Binary" is  
>> true now for Value_Text objects too.
>
>
> Wouldn't changing the class inheritance hierarchy of a public class  
> be a BC break as well? As you said, you nee

Yeah, I pondered this question too. And even though the classes have  
exactly the same API, changing the inheritance hierarchy is probably a  
BC break. A trait would be helpful here, but I guess an abstract base  
class would do too.

> Also, is $value being set to a stream really a BC break? This is  
> only the case when insert/updating a blob column, so it's the client  
> code that is setting it to a stream - which means it must already  
> have a dependency on a version of Horde_Db that can support it. Or  
> did I misunderstand something?

You never know what people do with the library, they could have  
extended on of the existing drivers that receive the Horde_Db_Value  
objects. I personally have been hit *inside* Horde_Db, though this  
could have been fixed without a BC break. But it's cleaner this way  
anyway.

-- 
Jan Schneider
The Horde Project
https://www.horde.org/