Etikettarkiv: PHP

En önskning till PHP-tomten

Som ni kanske redan har läst här på min fina blogg har jag dykt ner lite i PHP under föräldraledigheten. Säga vad man vill om PHP men med Laravel kan man ha riktigt kul och få en vettig projektstruktur på köpet. Två flugor i en smäll så att säga. Nåväl, nu efter ett par månaders hackande tänkte jag ta tillfället i akt att ändå gnälla lite eftersom det är det vi människor är bäst på. 😉

Det finns mycket som man skulle kunna gnälla över när ämnet är PHP, särskilt ur mitt perspektiv som (främst) Javaprogrammerare. Men alla språk har sina begränsningar, sin historia och sin ryggsäck, och om verktyget – det vill säga språket – inte passar ändamålet är det väl bättre att byta verktyg än att sura ihop? Med det sagt finns det ändå en stor grej som jag saknar vad det gäller objektorienteringen i PHP, och det är det här med package-private visibility. Ni vet, den där varianten där man i Java utelämnar visibility i till exempel en metoddeklaration. I Java innebär det att metoden endast kan anropas från klasser i samma paket. Det kan låta som lite ”jaha” men det är faktiskt någonting väldigt användbart när man modellerar. Genom att använda denna visibility på ett förnuftigt sätt kan klasser inom ett och samma paket samarbeta utan att man behöver exponera sånt som bara är relevant inom paketet ut mot resten av systemet. Ett paket kan då designas att endast ha ett fåtal metoder som går att anropa utifrån. Det gör att vi kraftigt kan begränsa interaktionspunkterna med koden i paketet vilket i sin tur ger oss bättre förutsättningar att ha en förvaltningsbar kodbas.

Ett enkelt exempel på när avsaknaden av package-private visibility ställer till modelleringsbekymmer är när man vill bygga sig en Factory som skapar objekt av Foo, vi kallar den för FooFactory. Eftersom vi vill att FooFactory alltid ska sköta konstruktionen av objekt av typen Foo kan vi då i Java sätta package-private visibility på konstruktorn i Foo. Eftersom vi har package-private visibility på konstruktorn har vi effektivt sett till att det inte går att skapa upp instanser av Foo från någon annanstans än inom dess paket. Vi kan sedan välja att publicera en metod ut publikt mot resten av systemet i FooFactory som konstruerar objekt av typen Foo efter konstens alla regler.

I PHP är det en annan historia. Eftersom det inte finns någon package-private visibility får vi snällt låta konstruktorn vara publik. Visst kan vi skapa upp en Factory – exempel på det finns här – men då får vi helt enkelt gilla läget och låta konstruktorn i Foo vara publik. Vi har då alltså exponerat två sätt att skapa upp instanser av Foo – dels genom Foos konstruktor och via FooFactory – men vi vill bara att den senare av dem ska användas. Hur ska man kunna försäkra sig om det? Tja, jag antar att man får ha disciplin och berätta för nytillkomna programmerare att de ska hålla sig borta från Foos konstruktor. Men modelleringsmässigt känns det riktigt trist. Om man nu har bemödat sig med att lägga till stöd för namespaces i PHP kunde de väl ändå peta in package-private visibility också.

Sådär, då var dagens I-landsproblem avhandlat. Tack för mig. 🙂

PHP och jag

Det är nu många år sedan jag först stiftade bekantskap med programmeringsspråket PHP. Språket var också det första jag verkligen lärde mig och har därför på något sätt alltid varit lite speciellt för mig. Lite som en gammal vän som jag av olika anledningar inte haft tillfälle eller anledning att hänga med på evigheter. Vi växte väl ifrån varandra, du och jag. Men hur kom det att bli så?

Under mina universitetsstudier vänstrade jag med bland annat Java och så sakteliga började jag inse att den flexibilitet som dynamiskt och svagt typade språk erbjuder inte alltid är av godo. Att reda ut en rejäl bytta spagettikod i ett språk med svag typning (t ex PHP) är inte kul någonstans. Det jag till en början hade hatat med Java – att kompilatorn var så jävla picky – kom att bli det jag nu ser som den överlägsna styrkan i språket. Tack vare Javas statiska och starka typning och rigida struktur får man goda förutsättningar för ordning och reda ”på köpet”, och ordning och reda är livsviktigt i projekt som involverar mer än en programmerare. Till och med som ensam programmerare har jag många gånger varit lycklig över att mitt fina IDE genom språkets egenskaper har goda förutsättningar att hjälpa mig med massor av grejer.

Jag minns att jag sa att jag aldrig mer skulle återvända till mitt fina gamla PHP, och bortsett från nåt script här och där för att lösa något mindre problem lite dirty har jag hållit fast vid det tills nu. Av en eller annan anledning valde jag för någon månad sedan att sparka igång PhpStorm och återse min gamla bekantskap. Kanske fanns det något mer än nostalgi att få ut ur vår gamla relation?

När jag stängde ner min laptop den kvällen insåg jag att jag hade haft skitkul.

Sedan vi såg varandra senast, mitt fina PHP och jag, vill jag minnas att det varken fanns namespaces eller interfaces. I vilket fall hade jag inte använt mig av dem då. Jag vill minnas att det inte fanns något vettigt sätt att hantera beroenden mot tredjepartsbibliotek. Nu finns det något som heter Composer som känns riktigt kompetent. Jag vill minnas att mitt IDE på den tiden det begav sig hade nada struktur att luta sig mot för att kunna vara till någon vettig hjälp. Nu har jag förstått att man via PHPDoc (typ som JavaDoc fast för PHP) kan använda sig av kommentarer för att ange typning på t ex variabler, förväntad returtyp på metoder och deras argument. Man lobbar alltså in en slags typsäkerhet som PhpStorm kan utnyttja för att kunna hjälpa till att hålla ordning och reda.

Låter det knäppt? Ja, det tycker jag, det är ganska weird. Men visst är det också lite charmigt? Alla medel verkar vara tillåtna när man pressar in feature på feature för att göra språket till något annat än vad det var ämnat till från första början. Kan en sax användas som en skruvmejsel?

Jag vill slutligen minnas att det inte heller fanns några vettiga ramverk att luta sig emot – min ”ramverksskepsis” till trots måste jag medge att det finns många fördelar med dem också – men efter att ha testat på Laravel kan jag bara konstatera att man här har ett utmärkt sådant. I ramverket har man – tro det eller ej – byggt in en IoC container och man använder sig av commands, events och andra arkitekturella fiffigheter som jag tidigare inte har sammankopplat med PHP. Enhetstestning, loggning och versionering av databaser är ytterligare saker man får ”out of the box” i Laravel. Sammantaget ger ramverket ett ganska kompetent och användbart intryck.

Anser jag PHP vara ett verkligt alternativ om jag ska bygga någonting större? Nej, jag väljer ett starkt typat språk vilken dag som helst. Men jag tror att man med dagens ramverksstöd kan bygga mindre applikationer med språket och samtidigt upprätthålla en någorlunda struktur som går att underhålla. På många sätt är mycket med språket lite knäppt; att behöva lobba in typning för ett IDE via PHPDoc kan knappt inte ses som någonting annat. Syntaxen erbjuder i mitt tycke inte heller förutsättningar för en särskilt vacker kodprosa. Men för mig känns det just nu väldigt tillgängligt, kul, lite trubbigt och charmigt.

Och visst är det coolt att skruva i en skruv med en sax – bara för att man kan?