PHP is not Java - and for good reason. PHP is a rather nice scripting language. PHP scripts are loaded and run for /each and every /request. In a sense every request starts with a compile. Clearly to keep the overhead down you don't want to be compiling in more than is needed to process the request.

Java is compiled once at development time, and once loaded stays loaded for all subsequent requests. With Java you pull in /everything/ during compilation that might be needed. Since you are pulling in a /lot/ more source, you need more structure to keep the code organized and understandable. Compiling in more than is needed costs you essentially nothing.

The payback using PHP is faster iteration during development. The payback using Java is greater efficiency - especially for complex processing.

Note also that given the disparity between network and CPU speeds, and with a little care in programming, even nominally less efficient PHP scripts can turn around requests at very respectable rates.

PHP simply should not need as much structure as Java.

BTW, another way to look at the problem is to consider a script as an object. The requests and options to which that script responds can be considered as methods. Include files can be viewed as inheritance. In a very real sense this is object-oriented programming without actually requiring support for object orientation in the language :).

IMHO - this is enough structure for PHP's role.


Manuel Lemos wrote:


Hello,

On 03/28/2003 05:34 AM, Marcus Börger wrote:

I have not had time to look this in detail so I could not reach a conclusion.

Is the upcoming object model supporting package level member access retrictions like in Java?

For those that are not aware of what is that, packages are a group of independent classes (not like nested classes).

The members with package level access restriction can only be accessed from functions of classes of the same package.




PHP is not JAVA.


I was not asking because Java has them but rather because package level access restrictions are a Good Thing (tm) for better access management organization between classes that belong to the same package.

Your comment is very curious because after all, many things have been copied from Java to Zend Engine 2 like: private, protected, public, final, abstract, interfaces, nested classes.

AFAIK, at least some of these things will make PHP 5 code execute slower than PHP 4 because they imply making additional checks at run-time, unlike Java and other languages that only enforce them at compile time.

Maybe I missed the reasoning about adding such features but it sounded to me like it was meant to make PHP have Java features.

Anyway, I am not suggesting or defending the support of package level access restriction, I was just asking if it would be made available, although it is odd that it will support private, protected and public and not package.


Adding Packages and restictions which do not even have a name? Who besides very expirienced
JAVA programers should understand it?


Duh?! I do not program in Java and I perfectly understand the point of package level access restrictions. Maybe you do not understand it because you are not used to develop packages of classes.

Although I just mentioned Java to help explaining clearly what I meant, in case you are not aware, I would like to add package is Java default access restriction mode (public in PHP and private in C++) because it is very common to ship classes as in packages.

Since Zend Engine 2 supports namespaces, it makes all the sense to support package access level restrictions as packages and namespaces are directly related concepts, not to say they the same thing.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to