PHP Framework

Ik heb een vraagje... in een van je bestanden zie ik dit:

<?php
define('PHP_SUFFIX', '.php');
define('INI_SUFFIX', '.ini');

// Define the directory seperator.
define('DS', DIRECTORY_SEPARATOR);
define('ROOT', dirname(__FILE__) . DS . '..');
define('CORE_FOLDER', ROOT . DS . 'core');
define('CORE_LIBRARY_FOLDER', CORE_FOLDER . DS . 'lib');
define('CLASSES_FOLDER', ROOT . DS . 'classes' . DS);
define('DATA_FOLDER', ROOT . DS . 'data');
define('CONFIGURATION_FILE', DATA_FOLDER . DS . 'configuration' . INI_SUFFIX);
define('CORE_LOG_FILE', CORE_FOLDER . DS . '..' . DS . 'data' . DS . 'logs' . DS . 'core.log');
define('ERROR_HANDLING_METHOD', "CoreErrorHandler::onError");
define('EXCEPTION_HANDLING_METHOD', "CoreErrorHandler::onException");
define('SHUTDOWN_HANDLING_METHOD', "CoreErrorHandler::onShutdown");
define('DEBUG', 2);

// Here we import the core classes.
include(CORE_FOLDER . DS . 'CoreConfigurationLoader' . PHP_SUFFIX);
include(CORE_FOLDER . DS . 'CoreState' . PHP_SUFFIX);
include(CORE_FOLDER . DS . 'CoreLogger' . PHP_SUFFIX);
include(CORE_FOLDER . DS . 'CoreException' . PHP_SUFFIX);
include(CORE_FOLDER . DS . 'CoreLibraryLoader' . PHP_SUFFIX);
include(CORE_FOLDER . DS . 'CorePharCreator' . PHP_SUFFIX);
include(CORE_FOLDER . DS . 'CoreErrorHandler' . PHP_SUFFIX);
?>

Het ziet er op zich netjes uit, maar wat ik me dus afvraag... waarom DEFINE je een PHP_SUFFIX, een INI_SUFFIX en een DS(directory separator)?

Dat verandert toch nooit? Is dat dan geen overkill? Vervolgens ga je uit al die defines je include-paden opbouwen wat volgens mij niet ten goede komt aan je performance.

Dit:

include(CORE_FOLDER . DS . 'CoreErrorHandler' . PHP_SUFFIX);

kun je toch gewoon vervangen door:

include CORE_FOLDER . '/CoreErrorHandler.php';

Beter toch?

Ten eerste, inderdaad, de PHP_SUFFIX verandert nooit, en daarom is het een constant (constantly variable)

Ten tweede heb ik wat benchmarks gedaan en:

Zonder Constants: Took 0.00025105476379395 miliseconds
Met Constants: Took 0.00065803527832031 miliseconds

Code 1:

<?php
$start = microtime(true);

include 'script.php';

$end = microtime(true);

echo 'Took ' . ($end - $start) . ' miliseconds';

?>

<?php
$start = microtime(true);

define('FOLDER', dirname(__FILE__));
define('DS', '/');
define('PHP_SUFFIX', '.php');
include FOLDER . DS . 'script' . PHP_SUFFIX;

$end = microtime(true);

echo 'Took ' . ($end - $start) . ' miliseconds';

?>

Dit schilt echter zo weinig dat ik me er niet ga over ontfermen.

Waar het mij om gaat is... waarom je alles in DEFINES stopt.

"Ten eerste, inderdaad, de PHP_SUFFIX verandert nooit, en daarom is het een constant (constantly variable)"

Ik ben gewoon benieuwd waarom je een bestandsextensie in een define stopt. Misschien zie ik het verkeerd, maar het komt op mij over alsof je het jezelf onnodig moeilijk maakt. Weet je wat laat ik eens in plaats van .php overal PHP_SUFFIX gaan typen. Die .php zal toch nooit anders worden... dat is eigenlijk wat ik bedoel.

Ik ben benieuwd hoe andere members hier tegenaan kijken...

@Ozzie

Ben het helemaal met je eens. Verder vind ik elk mogelijk tijdverschil toch niet onverstandig om is over na te denken. Je moet enigszins de keuze maken tussen snelheid (performance) en gemak. In dit geval denk ik dat op beide punten kan winnen, weg met onnodige constanten en dan volgt het twee ook. Time is money!

(typo)

Gelukkig iemand die mijn mening deelt :)

Dus grote PHP frameworks zoals CakePHP kiezen ook voor gemak?

https://github.com/cakephp/cakephp/blob/master/index.php

Ozzie PHP op 10/08/2011 22:37:08

Dit:

include(CORE_FOLDER . DS . 'CoreErrorHandler' . PHP_SUFFIX);

kun je toch gewoon vervangen door:

include CORE_FOLDER . '/CoreErrorHandler.php';

Beter toch?

Nee. Windows gebruikt '\' en Unix systemen '/'. Als je je framework op IIS wilt zetten dan hoef je enkel DS aan te passen als je het op de manier van Fabian doet.

Write Down op 11/08/2011 01:06:11

@Ozzie

Ben het helemaal met je eens. Verder vind ik elk mogelijk tijdverschil toch niet onverstandig om is over na te denken.

Als je het verstandig vind om rekening te gaan houden met een performancewinst van vier tienduizenste van een milliseconde dan ben je naar mijn inzien verkeerd bezig. Het is veel belangrijker om op een goede manier te coden en je script goed onderhoudbaar, portabel e.d. te maken. PHP performance optimalisatie is iets waar alleen de grote websites op het web zich druk om hoeven te maken. Veel belangrijker is om je content te comprimeren, gzippen, enzovoorts. Dat kan je een paar seconden laadtijd schelen.

Edit:
Mijn feedback over het framework: het is nog erg in opbouw. Wat ik zie ziet er opzich goed uit. In de class Object viel me het volgende op:

<?php
	/**
	 * Constructs a new Object.
	 */
	public function __construct() {
		$this->construct();
	}

	/**
	 * Constructs a new Object.
	 */
	public function construct() {

	}
?>

Dit lijkt me een beetje dubbel en ik zie er het voordeel niet van in. Een class die van Object overerft kan toch met parent::__construct(); deze aanroepen. Of wil je als het object al bestaat nogmaals construct() kunnen aanroepen?

MVC zou ik er echt gaan inbouwen. Ik zie ook nergens iets als autoloading ( http://php.net/manual/en/language.oop5.autoload.php ). Dat kan wel erg handig zijn voor lazy loading van objecten. Hoe wil je in de controller zo framework functionaliteit gaan aanroepen? $this->classname->method() vind ik zelf een fijne manier hiervoor.

Ben het met The Force eens.

Die benchmark slaat natuurlijk ook nergens op, je kunt niet met zekerheid stellen dat deze geldig is omdat de server op dat moment niet even met een ander proces bezig was. Het is beter om dezelfde test 1000x uit te voeren bijvoorbeeld per methode en dat te benchmarken.

Kees Schepers op 11/08/2011 10:38:49

Die benchmark slaat natuurlijk ook nergens op, je kunt niet met zekerheid stellen dat deze geldig is omdat de server op dat moment niet even met een ander proces bezig was. Het is beter om dezelfde test 1000x uit te voeren bijvoorbeeld per methode en dat te benchmarken.

Omdat PHP in een ander process wordt uitgevoerd, kan de server geen invloed hebben op het interpreteren van de PHP code/uitvoeren.