include, haakjes of niet?
Dus:
is er verschil tussen:
include ('mijnbestand.php');
en
include 'mijnbestand.php';
Zit er een verschil in snelheid, of maakt dat niet uit?
Indien het niets uitmaakt, wat is dan het meest gebruikelijk?
er zit geen verschil in snelheid en dit vind ik mooier,
aan de andere kant kan je ook zeggen, dat alle functies met haakjes geschreven worden, dus als je die regelmaat vasthoud krijg je include('mijnbestand.php');
Maar als je een goede autoloader stack hebt dan zou je niet eens include statements nodig hebben :)
Nou, daar ben ik nu precies mee bezig om die te maken :)
Maar ik moet natuurlijk vantevoren een paar filetjes includen..
Maar leuk hoor, ik gebruik (de oude) Zend Studio 5.5 en die editor ondersteunt geen namespaces. Dus nu ga ik het maar op de "ouderwetste manier" proberen. Dus:
$model = new BackEnd_Model_Test();
Alleen nu vraag ik me dus wel iets af. Ik heb zowel voor m'n cms als de website zelf een "models", "controllers" en "library" map waarin classes kunnen staan. Dus 6 mappen in totaal.
Nu wil ik dus aan de hand van de naamgeving aan de autoload functie laten weten waar ie het bestand moet zoeken.
Dus ik had bedacht dat ik dan de eerste 2 woorden extraheer, in bovengenoemd voorbeeld "BackEnd" en "Model" en dat ik dit dan vertaal in de juiste directory "/var/private/backend/models/" en dat ik dan in die map controleer of het bestand Test.php bestaat. Zo ja, dan include ik die (of beter include_once).
Is dat een goede manier denk je?
Gewijzigd op 08/02/2012 09:46:41 door Ozzie PHP
Dus: echo('hallo);
?
Maar waarom gebruik je Zend Studio? Als ik jou was zou ik overstappen naar NetBeans of Eclipse, of de nieuwste Zend Studio. Ik heb een aantal jaar Zend Studio gebruikt maar ben er geen fan meer van.
Wat je ook kunt doen is bijvoorbeeld de Zend_Loader auto loader gebruiken. Dan hoef je dat allemaal niet zelf te schrijven. Die kan met namespaces en de Classes_Met_Underscores omgaan. Als je wat Googled vindt je voldoende voorbeelden om de autoloader alleen los te gebruiken. Je hoeft daarvoor niet perse het hele framework te gebruiken (al zou ik dat wel doen :p).
Zend Studio (de oude versie) vind ik nog altijd het prettigste werken. Heb al veel andere editors geprobeerd, maar ik blijf terugkomen bij Zend Studio.
Zend Studio biedt eigenlijk alleen toegevoegde waarde als je ook echt Zend producten gebruikt. Dus bijvoorbeeld debuggen met Zend Server en dat soort dingen. 5.5 is ook al echt oud, maar vanaf alle versies daarboven werdt het voor mij onoverzichtelijk. Daarom gebruik ik nu NetBeans, heel veel mogelijkheden maar niet overdone en overzichtelijk.
Je zal later misschien wel meer behoefte krijgen aan een overstap als je unit testing toepast of bijvoorbeeld xdebug wilt integreren met je editor.
Wat betreft je autoloader manier, lijkt me opzich prima. Bouw je een eigen framework voor de leer curve? En waarom zou een eigen framework niet mogen bestaan uit componenten van andere frameworks?
De manier die omschrijft lijkt me prima. Dit is ook hoe de autoloader van ZF werkt. Ook zou ik proberen toch gebruik te maken van namespaces. Gebruik trouwens ook de spl autoloader en niet de PHP magic __autoload. Met de SPL autoloader kun je een stack maken van meerdere autoloaders :) Bijvoorbeeld een autoloader voor je viewhelpers, of models of framework classes, anders krijg je een enorme __autoload functie ;-)
Het framework is niet voor de leercurve, maar voor het echie :)
Wat bedoel je met spl autoloader? Ik gebruik nu de __autolaod, maar volgens mij hoeft die niet heel groot te worden?
Gewijzigd op 08/02/2012 11:02:31 door Ozzie PHP
Maar je kunt anders het beste even op de PHP manual kijken, dan begrijp je het wel denk ik.
Maar waarom een eigen framework? Heb je daar een reden voor? Of had je daar al een keer over gediscussieerd met mede leden? (kan me daar iets van herinneren iig)
Ik heb het even doorgelezen, maar ik snap niet exact hoe het werkt of wat het voordeel is. Ik denk dat ik het (voor nu) maar bij de gewone __autoload laat. Wellicht als ik in een later stadium kom, dat ik het nog aanpas, maar volgens mij red ik het wel met __autoload.
En tevens ben ik ruby gewent en daar zijn haakjes bij alles overbodig:
Code (php)
1
Page.should have_content => 'Hello world'
In PHP:
Code (php)
1
Page::should(have_content => 'Hello world');
Code (php)
1
12 * 10 in ruby is eigenlijk 12.*(10)
@kees, die spl loader ziet er mooi uit. Ga er eens goed naar kijken.
@Ozzie, ik merk dat je dus geen namespaces gaat gebruiken? (hoef ik je ook niet meer terug te mailen)
Edit:
De discussie is hier te vinden: http://www.phphulp.nl/php/forum/topic/eigen-framework-beheersysteem/75343/
Gewijzigd op 08/02/2012 11:34:00 door Wouter J
Wouter J op 08/02/2012 11:31:40:
@Ozzie, ik merk dat je dus geen namespaces gaat gebruiken? (hoef ik je ook niet meer terug te mailen)
Nee inderdaad. M'n (heilige) editor ondersteunt het niet :(
Dus inderdaad maar op de "oude" manier. Thanks for the help though! :)
Ozzie PHP op 08/02/2012 11:30:55:
Eigen framework zodat ik alles in eigen beheer heb en precies zo kan maken als ik het zelf wil. Op maat en efficiënt :) (de discussie is inderdaad al eerder gevoerd ;))
Ik ben echt absoluut geen voorstander van een eigen framework ontwikkelen. Zeker niet voor een commercieel product waar geld mee verdient moet worden (later). Maar goed, ik heb die discussie destijds links laten liggen volgens mij want heb er een hele duidelijk mening over maar die zal ik je besparen haha.
Ozzie PHP op 08/02/2012 11:30:55:
Ik heb het even doorgelezen, maar ik snap niet exact hoe het werkt of wat het voordeel is. Ik denk dat ik het (voor nu) maar bij de gewone __autoload laat. Wellicht als ik in een later stadium kom, dat ik het nog aanpas, maar volgens mij red ik het wel met __autoload.
Lees je mijn bericht wel? Ik leg volgens mij vrij duidelijk uit wat de voordelen zijn? Wat begrijp je er precies niet aan? Verder zou ik je toch wat meer verdiepen aangezien de __autoload door PHP zelf ook afgeraden wordt:
Quote:
spl_autoload_register() provides a more flexible alternative for autoloading classes. For this reason, using __autoload() is discouraged and may be deprecated or removed in the future.
Bron: http://www.php.net/manual/en/language.oop5.autoload.php
Net zoals echo, print, (+, -, ...), ( ? : ), ==, ...
Zie http://php.net/manual/en/language.operators.php
Die vereisen geen haakjes.
----
Een programmeertaal zonder operatoren, is vrij lastig.
Neem nu LISP
Wat in php zo gaat:
Code (php)
1
2
3
2
3
<?php
$a = ($b + $c) / $d;
?>
$a = ($b + $c) / $d;
?>
schrijf je in LISP zo:
Code (php)
1
2
3
4
5
2
3
4
5
(setq
a (/
(+ b c)
)
)
a (/
(+ b c)
)
)
Of stel dat je in PHP zoiets zou moeten doen:
Code (php)
1
2
3
2
3
<?php
=($a, /( +($b, $c), $d ) );
?>
=($a, /( +($b, $c), $d ) );
?>
Waarbij dus = een functie is, net zoals + en /.
Echt gezellig en overzichtelijk is dit niet he.
Leve de operaror!
"De SPL versie aan te raden omdat je anders mogelijk in de knoop raakt als je third-party software gaat integreren in je applicatie met de __autoload. Het voordeel van de SPL autoloader is dat je meerdere __autoloaders kan registreren."
Ik ben niet van plan om third-part software te installeren, en ik begrijp dus niet wat je bedoelt met meerdere autoloaders. Ik heb die pagina bekeken, maar ik begrijp niet wat ik met die spl_autoloader kan wat ik met __autoload niet kan. Wellicht kun je me een heel simpel voorbeeldje geven waardoor ik het licht ga zien? :-)