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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
