Description: ------------ With 0.2.0 things switched from public to the more aggressive private. I'm hoping to persuade you to use protected instead. Moving to protected allows for two things: 1.) Easily mockup Net_URL2 for testing 2.) Easier to work with when extending Net_URL2 Why extend Net_URL2 you ask? Glad you asked! Digg's Submission_URL extends from Net_URL2 and has all sorts of extra URL validation, checking and munging. I'm not suggesting you change to protected solely so I don't have to rewrite my own code, but I don't see why protected wouldn't be a happy medium :) Thanks!

All the private properties are accessible through get/set methods. Why not use these when testing or extending the class?

Because there's no good reason to have these variables as private. It's not like Net_URL2 is meant to be read-only as you've added setters. At the very least it'd have been nice to use __set() and __get() instead since that would have been backwards compatible. I've seen the use of private variables discouraged in my own proposals and in others as well (Services_Facebook is an example). Since then I've been converted as, unless the class is meant to be a read-only singleton, there's really no reason to make variables private and only leads to problems mocking them up and extending them later on.

> unless the class is meant to be a read-only singleton, there's really > no reason to make variables private I doubt there is general consensus about that in OO circles. I agree that encapsulation may make unit testing hard, but as long as all properties are paired with a setter, I don't think that is a concern in this case. My main concern is that by making the private fields protected or public, the inner workings of the class cannot be changed later on without breaking BC. For instance, it may turn out to be a good idea to represent the query string as an array rather than a string. WRT mocking and subclassing I don't understand why $this->_path = 'bar' is better than $this->setPath('bar') (except perhaps for being easier to read). Could you give an example of a problem that is caused by _path being private? I am not opposed to adding __get() and __set(), though.

A problem with testing is that I can't, without a doubt, know that $this- >_path actually contains what I think it should as getPath() may return something different than the actual variable. Let's use your example that it makes sense for $this->_path to be stored in an array. Let's say that getPath() returns a string. I can't really assert that the structure of that array is properly formed when it's private. If you'll add __get() and __set() and they'll be backwards compatible I'll shut up. :)

__get() and __set() were added in 0.3.0.