[dev] [commits] Horde branch master updated. 760524934f11365acac54b36a4ced40996062ebe

[Michael J Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>>> e6a7d00 Released Horde_Socket_Client-1.0.0
>>
>> I thought we made it clear that using namespaces in Horde 5 is NOT  
>> acceptable!? Why did you ignore what we said?
>
> This was an oversight.  While I disagree that anything was formally  
> decided, Horde_Smtp had a critical issue -- albeit rare -- that  
> needed to be fixed.  And there was no reliable way to do this  
> without releasing both since we don't have separate git repos for  
> libraries (git revert-ish like behavior is not acceptable).  I did  
> not think of namespacing issues when releasing Socket_Client.  But  
> it was the correct decision - the critical bug needed to be fixed.
>
> This doesn't affect anybody though.  I believe one of the arguments  
> against namespacing was "people won't know which form of namespacing  
> to use."  Huh?  That argument makes zero sense.  Either that or I am  
> a terrible coder because I need to look at the documentation before  
> writing a function call when apparently everybody else somehow  
> magically knows how to call Socket_Client's constructor which,  
> again, didn't exist until a week ago, and knows what sort of  
> Exceptions it may return.

This argument makes no sense to me. Yes, learning about a new library  
is a must before using it - but that has nothing to do with the fact  
that ALL of our Horde 5.x libraries do not use namespaces. Regardless  
if I have to look up how to call some method in a new library, I still  
need to remember it's a namespaced library. There is a difference in  
knowing what Horde_Foo::doSomeStuff() *does* vs having to rememember  
that Horde_Foo is really Horde/Foo while Horde_Bar:: is, well,  
Horde_Bar::.  Having some libraries namespaced and some not completely  
goes against the idea of having formal coding standards.

I think of it this way. If I were in a bookstore (remember those?),  
looking at the computer section, would I see a single book about  
coding with the horde framework libraries, or would I see dozens of  
books, one for each library we have? Even taking the more general  
argument about H5/H6 libraries out of the discussion, you have to  
agree that if you were reading a book about coding with the Horde  
Framework it would seem a bit odd that only 1 or 2 libraries are  
namespaced, wouldn't you?

>  I agree that you can't change EXISTING code.  But any argument  
> about a developer not being aware which namespacing method to use  
> for an entirely new library is completely disingenuous and simply a  
> non-starter for me.  So we can release a new major version of the  
> package just to change the namespacing rules, but that seems like a  
> waste of time for no gain.

This would be true (maybe) if the package was not part of a larger  
ecosystem that comes with certain expectations, and it still wouldn't  
solve the issue. It's not the *package* that needs to have the major  
version changed, it's *all* the packages. They may be independent  
packages, but they are still part of the Horde ecosystem and ALL of  
them should then be namespaced.

> Whether we want to do it or not is still an open question.  I'm not  
> convinced myself it is the correct way to go.

Personally, I don't see this as an open question. Horde 5.x code  
should NOT be namespaced. Period.

> But **PLEASE** stop using "Horde 5 library" as a justification here.  
>  THERE IS NO SUCH THING AS A HORDE 5 LIBRARY (with the exception of  
> Horde_Core)!!  I thought that was made clear long ago.

There *absolutely* is such a thing as a Horde 5 library. It's a  
library that must maintain BC with any Horde 5.x application. Adding  
libraries at will with different coding standards, incompatible APIs  
etc... AND USING THEM IN HORDE 5.x is not acceptable. If you want to  
call it something else, go ahead, it's just semantics, but the bottom  
line is all of the released framework libraries must be BC with each  
other and with our released applications, within the same major  
version number.

> Socket_Client has absolutely NOTHING to do with H5.  Nothing.

So, Socket_Client is not going to be used anywhere in H5 code? If  
somebody wants to develop an application that would fit into a Horde 5  
application stack, they would not be able to use Socket_Client, or  
Horde_Text_Filter or... ? That's what your statement above means to me.

> Horde_Text_Filter has absolutely NOTHING to do with H5.  Nothing.
> Horde_Support has absolutely NOTHING to do with H5.  Nothing.
> etc.

> Just because they all live together in our git repo doesn't change  
> any of this. This was all discussed long ago on the list.

And we had the same disagreement then as well.

I understand what you are saying, but even if the libraries are not  
"part of Horde 5" they still must follow at the very least the same  
coding standards and general requirements. To me, there is no  
difference in what you want to do vs making one library require PHP  
6.0 (or whatever) and the rest require 5.4 and use that library within  
a Core application. Library code that is used in any horde application  
must maintain the same CS and overall requirements.

> And I'll agree that the namespace decision might fall under the  
> rubric of general Horde coding standards.  But this decision has  
> nothing to do what we've done in other "H5 libraries", since that  
> term - outside of Horde_Core - has no meaning.

Sorry. Still disagree here. If we use Horde_Foo version 2.0 in Horde X  
release, that library, to me, is a Horde X library - meaning any code  
in that library must comply with Horde X coding standards and/or other  
general system requirements. We couldn't release BC breaking Horde_Foo  
version 3.0 and use it in a Horde X application, so why shouldn't we  
treat Horde_Foo 2.0 as a "Horde X" application in this context?

Do you know of any other project providing stand alone libraries that  
mix and match things like this in their stable code? Not being a  
smartass here, I honestly don't the answer to this.

> We absolutely must not be releasing new major versions of libraries  
> for H6.  Socket_Client is absolutely not going to be bumped to 2.0  
> for H6.  That's because Socket_Client has absolutely nothing to do  
> with H6.

Then maybe it shouldn't have been released until Horde 6 if you insist  
on keeping it namespaced.

Regardless, this is what we did going from Horde 4 -> 5 and is what I  
was expecting going from H5 -> H6. Though I don't care as much about  
*this* point as I do about the others. I.e., I don't care if we still  
use Socket_Client version 1.x in Horde 6 code assuming the API remains  
BC with Horde 5, and we don't bump it to 2.0 during the Horde 6  
release cycle.

> If there continues to be this belief that libraries are somehow tied  
> to applications, that is a core, fundamental issue I have that is  
> not going to change and makes me concerned going forward.

-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5849 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/dev/attachments/20131021/ca07ce16/attachment-0001.bin>