Re: Re: Class visibility in namespaces

Hi Franck,

we agreed long ago on a very easy scheme, there shall only be is-a and public classes.

Do you really think it makes the scheme "easier" to allow for public classes only?

Well, yes, actually.

Class visibility is a common OO concept, that improves the encapsulation of the code, and which, I'm afraid of it, will be requested again in the future, like typed return values and typed properties

Why be afraid of it? At least class visibility is something it's possible to add at a later stage, should a genuine need for it ever become apparent.

A recurrent scheme, on internals, is to underestimate the PHP developer's skills and needs.

Can I sell you a Google toolbar? :-) I promise you it'll be cheap!

Not only is this behaviour a bit upsetting for those who want to use PHP seriously, but in the long run, this may lead to insufficient specifications, or arguable conception choices. When PHP5 was designed, it was probably thought that a specific resolution operator would make it "easier" for a "PHP developer" to distinguish between static and non-static calls... and so "::" was introduced, in spite of the fact that "::" is for long a namespace separator in various languages.

"::" was introduced in PHP 3, not 5. Those 'various languages' you refer to barely existed at the time.

And no namespaces were added to the language by that time, because it was probably considered that a "PHP developer" would never need such a thing... even though namespaces have existed for long in many OO languages.

The first version of the Zend Engine with namespace support was rolled as a special edition of PHP 4.3.0 and released on php.net for public testing in 2002. This was originally scheduled for full release in PHP 5.0. (PHP is not, by the way, 'an OO language' in the sense you use the term.) It certainly wasn't withdrawn for the reasons you suggest. - Steph