static method maakt nieuw object?
Ozzie PHP op 12/06/2014 15:14:40:
Ik vond het zelf ook raar om autoloaders te gaan registeren en dan weer unregisteren, maar Dos en Ward geven aan dat dat gewoon voorkomt.
Als je packages van anderen gebruikt, kan het inderdaad gebeuren dat die "iets" met autoloaders doen. Maar op zich is dat registeren en unregisteren dan niet zo'n punt, want het is "maar" een autoloader.
Veel erger is een versimpelde class loader: een package waarin bijvoorbeeld een config.php twintig tot dertig keer require doet om alle klassenbestanden te laden. Die worden dan namelijk echt geladen, zelfs als ze niet direct of helemaal niet nodig zijn. Dan ben ik wel geneigd om die met comments buiten spel te zetten en mijn eigen autoloader aan het werk te zetten.
Daarmee zijn we weer bij het begin van dit topic, want je wilt een function library laden waarin één bestand alles regelt, maar dat vervolgens op eigen houtje met function_exists() gaat controleren of dat wel nodig is.
Dan schiet je, in een state-of-the-art OOP-framework anno 2014, wel je doel voorbij: alles als één bestand laden en vervolgens kijken of dat wel nodig is, is namelijk precies het tegenovergestelde van een autoloader die eerst kijkt wat nodig is en daarna alleen het benodigde laadt.
Ja, dat is ook wel vaag inderdaad. Je hebt sowieso een class, dus waarom zou je losse functies nodig hebben? Ik zou die functionaliteit er dan ook uitslopen.
Dat gezegd hebbende... wellicht is de Symfony component een beter alternatief, maar ik las wel ergens dat die vrij traag is.
Gelukkig zorg je er natuurlijk wel voor dat je in productie alleen de gecompiled configuratie laad, dus configuratie die al gecached is als geoptimaliseerde PHP code.
Ozzie PHP op 12/06/2014 14:16:11:
@Dos
>> Je hebt nu een deel van de uitleg onthouden terwijl de boodschap die je had moeten onthouden tussen de regels door te lezen is: micro optimization is the root of all evil.
Dat vind ik eerlijk gezegd wel een opmerkelijke uitspraak, want zo kwam het destijds niet over.
>> Je hebt nu een deel van de uitleg onthouden terwijl de boodschap die je had moeten onthouden tussen de regels door te lezen is: micro optimization is the root of all evil.
Dat vind ik eerlijk gezegd wel een opmerkelijke uitspraak, want zo kwam het destijds niet over.
Blijkbaar was ik niet sarcastisch genoeg toen ik je die slechte reden (maar nog steeds een reden =[) gaf om autoloaders te unloaden. Sorry.
Quote:
Wouter, als we je even mogen plagen... Het valt mij op dat de Symfony-documentatie configureren via PHP, YAML of XML als "gelijkwaardig" maar daarmee ook als "indifferent" behandelt. Als we er een minder "indifferent" naar kijken, wat is dan de beste insteek?
Binnen Symfony is PHP een soort van obsolete. Het kan wel, maar het is niet echt aangeraden. Als je je eigen applicatie gaat maken kun je wel voor PHP kiezen: Lekker makkelijk, geen goede met loaders en cachers enzo, etc.
XML is qua features veel krachtiger dan Yaml. Maar de kracht van Yaml zit hem weer in de eenvoud, je zou het zo aan iemand kunnen uitleggen.
De extra features die XML biedt is bijv. het definiëren van een XML schema (waarin elk toegestane element en attribute en hun waardes is gedefinieerd). Op deze manier kan je IDE autocompletion doen en kun je je XML ook valideren voordat je hem parsed.
Zou je dan, met de blik op oneindig (en het verstand misschien op nul), kunnen zeggen dat PHP zelf dan uiteindelijk obsolete wordt en je met Symfony compiled executables voor webservers kunt gaan maken?
Offtopic:
(Sorry voor het eventuele kapen van een topic, maar dit topic is toch al ontspoord.)
>> Blijkbaar was ik niet sarcastisch genoeg toen ik je die slechte reden (maar nog steeds een reden =[) gaf om autoloaders te unloaden. Sorry.
Ik had het inderdaad niet zo geïnterpreteerd. Dus volgende keer gewoon even overduidelijk sarcastisch zijn zodat ik me niet kan vergissen :) Excuses geaccepteerd uiteraard ;)
@Ward:
Ga je lekker, beetje m'n topic kapen?! Hehe...just kidding ;)
Ik denk niet dat PHP zal verdwijnen. Teveel websites draaien er wereldwijd op, dus no worries. Ik denk dat wat Wouter bedoelt is dat binnen een framework vooral naar universele overdrachtstypes wordt gekeken. Xml is volgens mij wat universeler/gangbaarder dan yaml en kan dus makkelijker worden uitgewisseld tussen systemen die van verschillende technieken gebruik maken. En daarnaast noemde Wouter ook nog wat extra voordelen van xml. Maar voor binnen je eigen applicatie is yaml prima geschikt. Leesbaar configureren! Verwoord ik het zo goed Wouter?
Rasmus Lerdorf heeft PHP uitgevonden om vooral maar niet in C en C++ te hoeven programmeren. Hij zocht een eenvoudige scripttaal als schil rond een complexe programmeertaal.
Nu proberen we die scripttaal in het keurslijf van een programmeertaal te persen. En meer dan dat: die scripttaal moet ook nog een objectgeoriënteerde programmeertaal worden.
Hoewel ik ook een PHP-fanaat ben, kun je je dus afvragen hoe houdbaar zo'n taal is.
Op het overdrachts ding na: Ja. Voor de overdracht tussen applicaties (lees, de APIs) is JSON gangbaarder.
>> Zou je dan, met de blik op oneindig (en het verstand misschien op nul), kunnen zeggen dat PHP zelf dan uiteindelijk obsolete wordt en je met Symfony compiled executables voor webservers kunt gaan maken?
Er zijn als PHP frameworks als C extensies beschikbaar: Phalcon. En je ziet nu ook dat de "Symfony environment" steeds verder overgaat naar het aanbieden van zowel een PHP als C versie, bijv. de Twig C extension.
Het omzetten van Symfony tot een PHP extensie zie ik niet gebeuren. Symfony heeft een tijdje geleden (samen met Twig) onderzoek gedaan of het handig is om dit te doen (bijv. sneller of veiliger, etc.). De winst bleek minimaal, te weinig om 2 versies (PHP en C) te gaan onderhouden.
Overigens zijn er wel andere mensen die Symfony componenten aan het omzetten zijn naar C extensies, bijv. de EventDispatcher extension.
Of PHP zelf ooit gaat verdwijnen? PHP denk ik niet, ik denk wel dat de ZendEngine (die PHP 4 en PHP 5 gebruikten) snel gaat verdwijnen.
De devs van de ZendEngine maken ruzie, staan betekend als mensen die nieuwelingen afzeiken en vrij conservatief zijn. Dan krijg je precies hetzelfde als een paar jaar geleden met de W3C is gebeurd: Er komt een team die gaat werken aan een nieuw project en nog een team en dan heb je dus NGPHP en HipHopPHP (HHVM). In het W3C geval werd W3C weer heel actief wat tot een ruzie tot op de dag van vandaag leidde, maar in PHP denk ik dat ZendEngine gewoon uitsterft en wordt overgenomen door 1 van die andere 2 en dat wordt dan weer PHP 6. Precies zoals na PHP 3 is gebeurd: Om de zoveel versies lijken de PHP developers gewoon weer toe aan een nieuwe engine.