extensies
Ik vraag me iets af. Beetje vreemde vraag wellicht.
Ik sla dus cache-bestanden op en die sla ik op in een "cache" map. Nu bedacht ik dat ik die cache-bestanden prima zonder extensie kan opslaan, want ze staan toch in een "cache" map dus het is duidelijk om wat voor bestanden het gaat.
Dus niet zo:
maar zo:
Is dat gebruikelijk? Is het slim? Of hebben extensies wellicht nog een ander nut, waardoor het niet slim is om ze weg te laten?
- Je kunt bestanden beveiligen op basis van de extensies.
- Je kunt via de extensie bepalen welk programma het bestand uitvoert.
Zit er PHP in een bestand, dan zou ik daarom gewoon de standaardextensie .php aanhouden.
>> - Aan de extensie kun je zien wat er in een bestand zit.
Klopt, maar dat kun je ook aan de map(naam) zien waar de bestanden in staan.
>> - Je kunt bestanden beveiligen op basis van de extensies.
Klopt ook. Maar wat als die bestanden buiten je webroot staan?
>> - Je kunt via de extensie bepalen welk programma het bestand uitvoert.
Klopt ook. Voor cachebestanden weliswaar minder relevant.
>> Zit er PHP in een bestand, dan zou ik daarom gewoon de standaardextensie .php aanhouden.
Dit is wel grappig. Ik heb even getest, en als je een php bestand zonder extensie opslaat, werkt het gewoon prima. Best maf :)
Maar je zou dus kunnen zeggen dat je ze in sommige gevallen nodig hebt, en in andere gevallen niet per se. Hmmm... voor de consistentie dan toch maar overal gebruiken?
Als je een directory /cache/ hebt, dan heeft de extensie .cache gebruiken inderdaad geen zin, dat ben ik helemaal met je eens.
Ward van der Put op 02/07/2014 12:37:30:
Zelf zou ik een afbeelding eerder als /images/logo.png en liever nog als /i/l.png opslaan
Mag ik vragen waarom?
Oké... maar waarom zou je het in dit geval niet doen? Gewoon even uit nieuwsgierigheid he... want dan zou je bijv. ook kunnen zeggen dat je al je bestanden in directory "classes" geen .php extensie geeft, omdat er toch alleen maar php bestanden in staan.
Wat is voor jou dan de reden om in een "cache" directory geen extensie te gebruiken? Waar trek je zeg maar de grens?
Elmar vH op 02/07/2014 12:40:54:
Mag ik vragen waarom?
Ward van der Put op 02/07/2014 12:37:30:
Zelf zou ik een afbeelding eerder als /images/logo.png en liever nog als /i/l.png opslaan
Mag ik vragen waarom?
Omdat het 8 bytes bespaart in élk request om dat ene plaatje.
Dat is een micro-optimalisatie die vroeger substantieel meer opleverde, alleen geldt het achterliggende principe nog steeds. Het is even wennen, maar bijvoorbeeld /i/, /c/ en /j/ gebruiken in plaats van /images/, /css/ en /javascript/ is niet zo onlogisch.
Ozzie PHP op 02/07/2014 12:46:13:
Wat is voor jou dan de reden om in een "cache" directory geen extensie te gebruiken? Waar trek je zeg maar de grens?
Ik zou juist wél een extensie gebruiken. Je slaat er nu misschien alleen PHP-bestanden in op, maar wie zegt dat dit zo blijft? Juist een cache moet je ontwerpen voor groei, in de breedte (meer bestanden van hetzelfde) én in de diepte (meer functionaliteit).
Gewijzigd op 02/07/2014 12:54:28 door Ward van der Put
Ah oké, dan begreep ik je even verkeerd.
Stel dat ik nu een object serialiseer en opsla in een cache-bestand, hoe noem je dan de extensie van zo'n cache-bestand? De extensie .php lijkt me niet kloppen, want er staat geen php in.
En stel je hebt bijv. een directory met logbestanden, bijv. de apache log en de php log. Wat is daar dan een logische extensie voor? Ik zou niks anders weten dan simpelweg .log, maar dan heb je dus een mapje "logs" met bijv. een apache.log en een php.log. Raar, of niet raar?
Wáárom gebruik je een extensie? In de eerste plaats vooral om duidelijk te "labelen" en "stickeren": een extensie plak je aan een bestand om te beschrijven wat erin zit.
Voor serialized PHP-objecten is .txt dan inderdaad logischer dan .php. Het is immers meer tekst dan PHP. Alleen... waarom dan niet voor absolute duidelijkheid gaan met bijvoorbeeld de dubbele extensie .txt.php of .serialized.php?
Iets kan twee dingen tegelijk zijn, dus we kunnen dat ook laten zien door er dan twee stickers op plakken, precies zoals je .js voor JavaScript hebt naast .min.js voor minified JavaScript.
Ah oké, goed punt. Da's inderdaad geen gek idee! Maar wat doe je dan met de extensie van een logbestand?
Dan denk ik dat ingesleten gewoonten toch het meeste moeten gelden. Iemand die bij problemen op zoek gaat naar log files, zal naar de extensie .log zoeken.
Zijn van die dingen waar je eigenlijk weinig bij stilstaat, maar wat toch nuttig is om even over na te denken :)
Ik denk dat usability meespeelt. Het soort bestand afleiden aan de extensie (die dus deel van de naam is) lijkt makkelijker voor onzen hersenen dan het weet ik veel waar in de interface te moeten zoeken in welke map het bestand staat.
Dat zou zomaar kunnen Dos. We zijn er aan gewend waarschijnlijk. Maar strict gezien zou je dus alles, wellicht met uitzondering van index.php, zou je dus alles extensieloos kunnen doen :) Ergens ook wel komisch :)
Als je Apache gebruikt is het een kwestie van een instelling in je httpd.conf wijzigen:
DirectoryIndex index
> Ergens ook wel komisch
Ik lach niet...
Bij Unix-achtige filesystems heeft een . geen specifieke betekenis. Het is gewoon een teken in je bestandsnaam. Extensies zijn iets wat tussen de oren van de gebruiker zit. Bij filesystems die onder MS-DOS of Windows worden gebruikt is de extensie echter een aparte namespace.
En eerlijk gezegd vind ik het voornamelijk irritant dat executables onder Windows per se een bepaalde extensie moeten hebben om ze te kunnen starten. En nog irritanter vind ik het dat de Explorer standaard de extensies verbergt, maar dat terzijde...
Maar ben jij geen voorstanden van extensies dan? Omdat je zegt dat het iet is "wat tussen de oren van de gebruiker zit"?
Wel ben ik tegen de manier waarop Windows omgaat met extensies, maar het gaat een beetje buiten de scope van deze discussie om dat uit te leggen. ;-)
Ah oké, helder. Het is dus eigenlijk vooral om het ons, mensen, wat makkelijker te maken?
>> Wel ben ik tegen de manier waarop Windows omgaat met extensies, maar het gaat een beetje buiten de scope van deze discussie om dat uit te leggen. ;-)
Nou, laat het dan toevallig "mijn" discussie zijn... ;) Brand los zou ik zeggen...