Hello guys,
I just had to write you guys to give you some "real-life" examples.
We're working here at a PHP framework, named ALFA PHP Framework, that's
rather unique in the way that it enforces strong types in every method
(using classes for basic data types). We have our files organized this way:
- /inc/ directory = all BASE classes, auto-loaded by a "cached"
scandir (), loaded in a carefully calculated sequential order.
- /mod/user_authentification
- /mod/admin_cp - which are two MODULE classes that we load when we
need more functionality. We selectively load any modules we need.
As a benchmark, we have somewhere around 10 BASE classes, in 10 PHP
files, and about 10.000 LINES, and loading them takes just 0.00024 seconds
on a Core Duo machine. (0.0006 on an uniproc). We've actually gone further
and we "bypass" some scandir () methods by cacheing them in the _SESSION
variable, if we detected a proper user session once the platform has been
loaded. We don't use __autoload because it doesn't fit our need for
"carefull organized loading".
My conclusion is, that any "real-life" application, well-designed
would do "auto-loading" just for some base-classes, like we do here, and any
other dependencies like "developer required modules", will be cached some
way. We for example do a /per user caching of information, but other
developers can find other mechanism to cache this information, like a DB
result, or anything else.
I for once disagree with "each target (like each page, MVC action,
etc.) would have its own huge PHP file that has all classes used there",
because real-life apps need a dynamic approach, and as said earlier, any
GOOD designed app, will inherently think of a caching mechanism for it's
"loading/require/include" scheme. To accomplish this we actually went for
require_once on a module using an object $MOD->activateRegisteredModule
('user_authentification') - which scandirs () the array, caches the array,
quickly loads them in succession.
In the case of namespaces, PHP should be tunned for PHP classes
loaded in succession, or, if that is a problem, make the parser add
clases/code to the namespace when it detects a "namespace Something" token.
Regarding the need of PHP developers to have extensive C++
knowledge, I really don't care. I come from a C++ background, and any PHP
developer that doesn't understand C++ cannot be called "a developer". Guys,
I work as a Software Architect in Bucharest, Romania, and the quality of PHP
developers is questionable, due to the "easiness" of the PHP language. If
any amount of complication is needed, do it, and stop worrying about "PHP
developers". Real-life PHP developers are on this mailing-list, talking to
you guys, issuing bugs, doing real-life work. Don't make sacrifices just to
keep the language simple. Just go "full throttle forward!"
Regards,
Catalin Z. Alexandru
-----Original Message-----
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 02, 2008 8:02 PM
To: Marcus Boerger
Cc: Gregory Beaver; Lukas Kahwe Smith; PHP Internals List
Subject: Re: [PHP-DEV] Re: namespace RFC
Hi!
> My guess is that it allows for development with heavy __autload usage and
> then doing deployment based on static analysis where each target page
> results in one large php file generated from that analysis. So there won't
> be any overhead and each script target would be a single target of its
own.
So each target (like each page, MVC action, etc.) would have its own
huge PHP file that has all classes used there? I guess for some
applications that could work, for others, more dynamic, that would fail
miserably. The maintainability of such thing is also challenging.
It would be nice to have some real-life examples of how such things work
out - so far I have seen only theory and synthetic benchmarks, which are
interesting, but not necessary what would happen on real project.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
