[PHP] (te)veel brakke code

[PrisonerOfPain]

djluc schreef op 05 juli 2004 @ 13:53:
Is IMO not-done. Wat is het nut van die quotes?

Geen idee, maar ik vind het echt enorm ranzig overbodig en een teken van onkunde

[Mac_Cain13]

djluc schreef op 05 juli 2004 @ 13:53:
[...]
Is IMO not-done. Wat is het nut van die quotes?
[...]

Dat is er niet en het is idd ranzig. Het was ook alleen om aan te tonen wat het verschil is tussen ' en ". Het is me iig nu duidelijk dat ik eigenlijk ' zou moeten gebruiken tenzij ik \n oid wil gebruiken. Tnx!

[AtleX]

Na de discussie over single- of double-quotes wil over naar het volgende onderwerp: Commentaar.

Daar kunnen mensen mee prutsen, of ze gebruiken het helemaal niet. Of ze becommentariseren elke regel die ze typen.

Ik zet boven elke gebruikers-gedefinieerde functie een kort stukje dat beschrijft wat de functie doet, welke paramaters er verwacht worden en wat de return-values zijn. Bij rare/afwijkende/ingewikkelde dingen zet ik daar ook weer een regeltje commentaar bij.

Het belang van goed commentaar is imho erg groot. Je moet over 3 maanden ook nog weten waarom je iets zo hebt gedaan. Ik heb weleens met iemand samengewerkt die 3 dingen verkeerd deed:
1) Geen commentaar
2) Copy-pasten van code. In 1 bestand 3 keer dezelde code tegenkomen is lastig debuggen
3) Niet inspringen

[Verwijderd]

AtleX schreef op 05 juli 2004 @ 13:48:
Als je enkele quotes gebruikt hoeft PHP de string niet te parsen op zoek naar variabelelen. Theoretisch is het dus sneller. Ook ziet het er wat netter uit en is een variabele beter te onderscheiden van de omliggende tekst.

RwD schreef op 05 juli 2004 @ 13:50:
[Crisp over single en double quotes]
Niet nodig en langzamer...

...knip...

Dit is echt zo niet waar. Of je nou single of double quotes gebruikt maar geen
ene hol uit qua tijdwinst. De tokenizer moet in beide gevallen gewoon netjes blijven
zoeken tot er een sluit quote (single of double) gevonden is. Die twee extra cases
doen het hem niet...
Uit de benchmark blijkt ook dat er geen verschil is tussen de twee varianten.

http://www.nextavenue.com/double.php
http://www.nextavenue.com/single.php

PHP:

$mtime = microtime(); 
$mtime = explode(" ",$mtime); 
$mtime = $mtime[1] + $mtime[0]; 
$starttime = $mtime; 

$t = 0;
for ($i = 0; $i < 10000; $i++) {
  for ($j = 0; $j < 250; $j++) {
    $a = 'blaat dit is een lange stringa';
    $b = 'blaat dit is een lange string.';
    if ($a == $b) {
      $t++;
    }
  }
}

$mtime = microtime(); 
$mtime = explode(" ",$mtime); 
$mtime = $mtime[1] + $mtime[0]; 
$endtime = $mtime; 
$total = $endtime - $starttime; 
echo $total;

[MisterData]

String array indices gebruiken zonder kwootjes is ook heel erg:

PHP:

<?php
$array = array();
$array[mijnarraykey] = "iets";
?>

enzo....

[Erkens]

MisterData schreef op 05 juli 2004 @ 15:32:
String array indices gebruiken zonder kwootjes is ook heel erg:

PHP:

<?php
$array = array();
$array[mijnarraykey] = "iets";
?>

enzo....

dat geeft bij mij altijd heel mooi een E_NOTICE

---

zelf gebruik ik eigenlijk altijd single quotes, ook als ik newlines moet hebben doe ik altijd single quotes:

PHP:

define('CR',chr(10));  // ja ik weet het, dat is linefeed,
                       // alleen carrige return vind ik duidelijker :P

..

echo "blaat", CR;

[Apache]

Ik ben het er mee eens, al lang trouwens.
De slechte reputatie van PHP als traag e.d. komt volgens mij ook vaak door slechte code die er rondzwerft op het internet.

Ook van PEAR word ik niet zo heel erg blij, maar das vnl omdat ik al wat langer met PHP 5 werk.

Ook wat crisp zegt, goede html erg belangrijk, natuurlijk gescheiden van de business logic, de xml tussenstap heeft voordelen, zoals al genoemd caching, maar in combinatie met XSL ook nog een mooie skinning engine.

Veiligheid is ook nog absoluut een punt, er zijn hopen sites waar je dmv een GET variable aan te passen andere, soms niet voor je ogen bedoelde informatie kan krijgen, ik schreef me ooit in op een php site, ik kreeg een tekstje in de zin van: "Welkom $gebruikersnaam, je passwoord is $passwoord."
Nu was dit in een popup en kreeg je niet meteen de URL hiervan te zien, maar ff view page info in mozilla, url kopieren, in gewone browser: welkom.php?user=$mijnuid

Nummertje veranderen en je kon andere gasten hun username & passwoord zien (erg moeilijk om dan met die account in te loggen ).

Een ander voorbeeld was SQL injection bij een van de grootste ISP's van België die een lanparty organiseerden, ingeschreven personen konden inloggen en hun gegevens wijzigen. Geen addslashes, dus als username (die je uit een lijst kon c/p'n) met een single quote, punt-komma en twee streepjes (commentaar in sql) (';--) en je kwam op die persoon z'n account

Zelf heb ik mijn grootste frustraties opgelost met wat collega studenten door een eigen framework op te bouwen, zoals pear hoeft het ook slechts op één plaats op de server te staan zodat een geupdate versie ook meteen alle bugs fixed in alle apps die ermee geschreven zijn.

_{Warning volgende code fragmenten bevatten aardige java ripoff}

PHP:

<?php
include('../zen-ng/zen.php');
zen::import('/core/http/request.class.php');
zen::import('/core/ui/listview.class.php');
zen::import('/core/tpl/tpl.class.php');
zen::import('/core/error/fileLogger.class.php');
zen::import('/core/error/mailNotification.class.php');
zen::import('/core/error/socketNotification.class.php');
?>

Die error handling classen zijn eigenlijk ontstaat vanuit het feit dat ik errors netjes wilde weergeven, maar het is meteen ook wat uitgebreid geworden met zogenaamde "debugdrivers" waarmee we meteen als developer verwittigd kunnen worden bij een error, een vriend heeft PET ontwikkeld waarmee je à la msn errors krijgt. [screenshot] [screenshot]

PHP:

<?php
/* 
de eerste parameter is null, maar kan een array bevatten met files 
waarvan hij de source niet mag tonen (kan ook volledig uitgezet worden)
zie eerste screenshot
2de parameter bevat de directory waar de error template zich bevind
die kan in de lokale applicatie overriden worden met een eigen template per app
en de 3de is de error reporting level 
*/
new ErrorHandler(null, zen::path().zen::tplPath, E_ALL); // template based

/* hier word er notification gestuurd naar een socket, kan ook een file, 
sqllite db, e-mail zijn, en zodra er jabber classes zijn ook een jabber versie
erg handig als je met 4 developers aan een project werkt met een stuk of 20 testusers, 
moeten ze niet meer manueel in een mailtje zeggen van woops er ging wat fout, weet niet weer, 
weet niet wat maar je hebt meteen alle uitgebreide informatie die je maar wil
*/
ErrorHandler::registerNotificationDriver(new errSocketNotification('10.0.0.2', 666));

/* dankzij php5 kunnen we hier ook een erg uitgebreide interface voor maken 
en typehinting gebruiken als parameter voor de registerNotificationDriver functie */

interface errorNotificationDriver {
    
    public function raiseError($errno, $errstr, $errfile, $errline, $vars);
    
}

    /**
    * @return void
    * @param errorNotificationDriver $end
    * @desc registers a notification driver that will be excecuted when an error occurs
    */
    static public function registerNotificationDriver(errorNotificationDriver $end){
    
        ErrorHandler::$notificationList[] = $end;
    
    }
?>

Wat ook meteen het punt van documentatie duidelijk maakt, er zijn standaard pakketten als phpDoc en javaDoc achtige toestanden die hieruit prachtige html bestanden kunnen genereren, de Zend development enviroment gebruikt ze dan ook nog eens bij de auto completion zodat je niet manueel naar de docs moet gaan kijken.

Voor de security is er de dbl die alles afhandelt dmv arrays en daar zelf de escape functie over haalt, t'is in de stijl van de key is veld dat geupdate moet worden en de value eraan is de nieuwe waarde.

En voor de GET/POST vars is er de request classe ism de Type classe, je krijgt bijvoorbeeld een warning wanneer je een $_GET['onbestaandeGetVar'] doet, een simpele wrapper functie lost dat op en daar kan je dan meteen typing doen desgewenst.

PHP:

<?php
    /**
    * @return mixed
    * @param mixed $index
    * @param integer $type
    * @desc returns a get variable but with isset and optional type checking
    */
    public static function get($index, $type = null){

        if (isset($_GET[$index])){
        
            if (is_null($type)){
            
                return $_GET[$index];
            
            } else {
                
                return Type::setType($_GET[$index], $type);
                
            }
        
        } else {
            
            return false;
            
        }
    
    }
?>

PHP:

<?php
$id = Request::get('id', Type::INTEGER);
?>

Ook de herbruikbaarheid van templates voor userinterfaces vond ik beter kunnen, hoe vaak zit je niet opnieuw een tabel volledig uit te typen.

Nu laat de template engine dit toe door een dir met standaard templates te hebben zoals een listview achtig iets, natuurlijk heeft de klasse die dit produceerd dan wel een instantie nodig van de Template engine, daarom moet die dus eerst aangemaakt worden en geregistreerd bij de Framework classe:

PHP:

<?php

zen::register(new Template('bleh.tpl'));

// in de Listview class:
$tpl = zen::getInstanceOf('Template');

// properties instellen van de listview:
// data kan ook rechtstreeks uit de Database layer komen
$lvwParams['data'] = array(array('bleh', 'blah', 'blehz0r'), 
array('blahz0r', 'bloeh', 'bloehz0r'), 
array('','blieh',null), 
array(null, null, 'bleh'));
$lvwParams['headers'] = array('naam', 'voornaam', 'bleh');
$lvwParams['highlight'] = 'naam';
$lvwParams['selectname'] = 'id';
$lvwParams['listmode'] = Listview::LVW_SELECT;

new listview($lvwParams);
?>

Wat er dan uiteindelijk zo komt uit te zien:


Nogmaals geef ik Crisp nog eens gelijk en vindt ik dat niet alles serverside moet, zo heb ik bij m'n isp slechts statische ruimte ter beschikking wat me dwong creatief te zijn, uiteindelijk zijn er wel server side scripts die lokaal draaien en thumbnails maken pagina's genereren en die via ftp doorstuurt naar m'n static webspace, maar daar heb ik dan zoveel mogelijk met JavaScript gewerkt om een dynamisch feel te geven, en uiteindelijk ziet het er nu allemaal vlotter uit omdat er geen postbacks zijn, slideshow kan zonder page reloads of andere truukjes. [vb] (slideshow wanneer je op een thumb klikt)

Nu vrees ik dat deze post veels te lang geworden is (t'regent buiten ), maar ik hoop vooral dat mensen hier wat originele ideeën uit kunnen putten en php misschien een beetje positiever bekijken, natuurlijk zijn dingen als dit ook vrij persoonlijk (coding/documenting style) maar dat heeft niet meteen iets te maken met security gaten die ontstaan in je web app.

Ik hoop dat met de komst van PHP 5 er een kwaliteitsverbetering komt in de source base die openlijk beschikbaar is. Een standaard reporting level van E_ALL of beter nog E_STRICT ( ) zou al een hoop schelen bij beginners
Niet te vergeten dat ook E_ALL code langer zal blijven draaien terwijl PHP in versie nummers stijgt en compatibiliteit breekt, zoals met superglobals het geval was.

Een jaar geleden heb ik trouwens een tutorial/code guideline-achtig iets gemaakt (35 bladzijden) maar das al vrij hopeloos outdated en heeft ook niet echt een groot publiek bereikt, iets wat het probleem is met veel tutorials denk ik. Wanneer je als team werkt aan een professioneel PHP project lijkt het mij wel nuttig om zoiets op te stellen als het al niet aanwezig is.

edit:

@AtleX: woei, graag gedaan
Nog 2 kleine tips:
drm's tiplist: http://gerard.yoursite.nl/got/php-tiplist/
en ACM had een PDF geschreven over beveiling van web applicaties, heb er geen url meer van, maar als hij dit leest wil hij hem misschien nog wel eens posten, k'heb em toen iig doorgenomen en vond hem wel nuttig (maar ik kan de pdf zelf ook niet meer terugvinden maar denk wel dat het van hem was )

[ Voor 10% gewijzigd door Apache op 05-07-2004 16:00 ]

[AtleX]

offtopic:
@Apache: Je post is niet nutteloos geweest. Je bracht me op een idee om een probleem op te lossen waar ik al 3 uur aan bezig was.

[ Voor 6% gewijzigd door AtleX op 05-07-2004 15:46 ]

[creative8500]

Hierbij mijn benchmarks betreffende de enkele/dubbele aanhalingtekens:

PHP:

<?php

require_once '../timer.php';

define ('limit', 2500000); // two and a half million

$results = array
(
    'single-quote' => (float) null,
    'double-quote' => (float) null
);

$BenchmarkTimer = new AutomaticBenchmarkTimer;

for ($i = 0; $i < limit; ++$i)
{
    $string = 'hier de test-string';
}

$results['single-quote'] = $BenchmarkTimer -> flush ();

for ($i = 0; $i < limit; ++$i)
{
    $string = "hier de test-string";
}

$results['double-quote'] = $BenchmarkTimer -> flush ();

header ('Content-Type: text/plain');
print "single: {$results['single-quote']}\ndouble: {$results['double-quote']}";

?>

Van dit script heb ik drie varianten, met daarin respectievelijk de volgende strings:

1. Avm # 6^% @ ml A_-12^*mw l31^`1 -> ]
2. Avm # 6^% $@ ml A_-12^*mw l31^`1 -> ]
3. Avm # 6^% \$@ ml A_-12^*mw l31^`1 -> ]

De testresultaten:

code:

VARIANT 1:
  poging 1:
    single: 2.32321882248
    double: 2.32834410667
  poging 2:
    single: 2.34591889381
    double: 2.33790397644
  poging 3:
    single: 2.29426908493
    double: 2.30964899063

VARIANT 2:
  poging 1:
    single: 2.33482122421
    double: 14.0099129677
  poging 2:
    single: 2.3703520298
    double: 13.3962008953
  poging 3:
    single: 2.32201814651
    double: 13.3124818802

VARIANT 3:
  poging 1:
    single: 2.36283707619
    double: 2.33323597908
  poging 2:
    single: 2.32685208321
    double: 2.34363484383
  poging 3:
    single: 2.27271413803
    double: 2.32194685936

Testomgeving:

• Windows XP
• Apache 2.0.49
• PHP 5.0.0RC3
• 1,7GHz Pentium-M

[AtleX]

Is het verschil bij variant 2 te verklaren? Volgens mij komt dat door die toegevoegde $

[Verwijderd]

AtleX schreef op 05 juli 2004 @ 16:14:
Is het verschil bij variant 2 te verklaren? Volgens mij komt dat door die toegevoegde $

yep, bij de 2e variant moet ie kijken wat er na de $ komt om te zien of het niet per ongeluk een variable is die ingevuld moet worden.

[AtleX]

Conclusie, singele-quotes is over het algemeen toch sneller?

[Verwijderd]

AtleX schreef op 05 juli 2004 @ 16:18:
Conclusie, singele-quotes is over het algemeen toch sneller?

Als je in je string een $ gebruikt terwijl dat niet nodig is (wanneer je in die string geen variabele gebruikt...) => Dan is single quote sneller.

Dus:

Het maakt qua snelheid pas uit, wanneer je dollartekens gaat gebruiken...
Zolang je geen dollartekens gebruikt, maakt het qua snelheid niets uit... Nou ja iets, want ook \n, \t etc moet geparsed worden

[ Voor 24% gewijzigd door Verwijderd op 05-07-2004 16:37 ]

[AtleX]

Verwijderd schreef op 05 juli 2004 @ 16:25:
[...]


Als je in je string een $ gebruikt terwijl je in die string geen variabele gebruikt...

Het maakt qua snelheid pas uit, wanneer je dollartekens gaat gebruiken...

Eehm, wat is het verschil tussen een dollarteken en $?

[crisp]

Verwijderd schreef op 05 juli 2004 @ 16:25:
[...]

Het maakt qua snelheid pas uit, wanneer je dollartekens gaat gebruiken...
Zolang je geen dollartekens gebruikt, maakt het qua snelheid niets uit... Nou ja iets, want ook \n, \t etc moet geparsed worden

Dit:

PHP:

$var = 'Hallo ' . $naam;

is sneller dan:

PHP:

$var = "Hallo $naam";

Ik gebruik altijd single quotes omdat het zich voorspelbaar gedraagt in alle gevallen.

[AtleX]

@Crisp:
Ik werk ook altijd op die manier. Niet alleen omdat het sneller is, maar het is ook beter leesbaar. Vooral in editors met syntax-coloring kan je sneller de code doorlezen op zoek naar fouten.

[Erkens]

crisp schreef op 05 juli 2004 @ 16:50:
Ik gebruik altijd single quotes omdat het zich voorspelbaar gedraagt in alle gevallen.

en dat is juist de reden waarom men single quotes moet gebruiken. Niet die paar microsec tijdswinst die je eventueel ermee kan behalen.

[PrisonerOfPain]

crisp schreef op 05 juli 2004 @ 16:50:
[...]

Dit:

PHP:

$var = 'Hallo ' . $naam;

is sneller dan:

PHP:

$var = "Hallo $naam";

Ik gebruik altijd single quotes omdat het zich voorspelbaar gedraagt in alle gevallen.

PHP:

$var = "Hallo {$naam}";

Is het snelst en IMHO het leesbaarst/makkelijkst omdat je de '.' nogal eens over het hoofd ziet

[ Voor 23% gewijzigd door PrisonerOfPain op 05-07-2004 17:03 . Reden: hehe, ja met een ' werkt dat niet nee.. ]

[Erkens]

PrisonerOfPain schreef op 05 juli 2004 @ 16:53:
[...]

PHP:

$var = 'Hallo {$naam}';

Is het snelst en IMHO het leesbaarst/makkelijkst omdat je de '.' nogal eens over het hoofd ziet

als je letterlijk 'Hallo {$naam}' in die var wilt hebben wel ja

maar hoe kan je met een goede editor die punt over het hoofd zien

[ Voor 16% gewijzigd door Erkens op 05-07-2004 16:58 ]

[Apache]

Het leest niet makkelijker want als je zo'n hele zin hebt zie je niet meteen dat er nog maar een variable op die lijn staat

Ik gebruik iig ook single quotes & concateneer wanneer nodig, zoals het ook in andere talen gebeurt, kan je trouwens aantonen dat {} sneller is dan single quotes en concateneren?

[Verwijderd]

Ik werk zelf nogal vaak met sprintf en de verwante functies. Als je 3 of meer variabelen in een string moet zetten gaat dit al sneller dan met:
• dubbele quotes en concatenation
• enkele quotes en concatenation
• dubbele quotes en in-string variabelen

Zonder variabelen is sprintf een kleine 3 keer trager, dat is dus niet zo heel handig om te gebruiken.
Met 1 variabele is het ongeveer 30-35% trager dan concatenation, maar is het al sneller dan een string met dubbele quotes en PHP variabelen erin.
Met 2 variabelen is het ongeveer 20-25% trager dan concatenation, en veel sneller dan dubbele quotes en in-string variabelen.
Met 3 variabelen is het ongeveer even snel als concatenation.
Met 4 variabelen of meer wint sprintf het, zeker als er ook nog eens expliciet getypecast moet worden.

sprintf kent ook nog eens een aantal handige extra'tjes zoals padding, number formatting, etc.

Ik gebruik dus bij voorkeur enkele quotes en (s)printf als er met variabelen wordt gewerkt. Je kunt ook eventueel sprintf en dubbele quotes gebruiken zolang je geen ongeëscapete dollartekens in je strings gebruikt.

[PrisonerOfPain]

Erkens schreef op 05 juli 2004 @ 16:58:
[...]

als je letterlijk 'Hallo {$naam}' in die var wilt hebben wel ja

Ik zou zweren dat daar "Hallo {$naam}" stond, maar ik zal het even aanpassen

maar hoe kan je met een goede editor die punt over het hoofd zien

Nou over het hoofd zien, vergeten :x als ik met een aantal regels klaar ben doe ik altijd even een "alt+tab" en "f5" om de laatse wijzigingen te zien en heel vaak bleek ik een '.' te zijn vergeten (en het is een hel als je dan moet gaan zoeken waar je die punt moet zetten) het ligt niet zo zeer aan m'n editor hoor (die is geweldig) maar aan het lettertype die maar een pixel voor een punt reserveerd.

@Apache, ik heb dat ooit gebenchmarked, ik zal het eens opzoeken (de resultaten staan wel ergens op internet)

[ Voor 12% gewijzigd door PrisonerOfPain op 05-07-2004 17:04 ]

[Erkens]

PrisonerOfPain schreef op 05 juli 2004 @ 17:03:
Nou over het hoofd zien, vergeten :x als ik met een aantal regels klaar ben doe ik altijd even een "alt+tab" en "f5" om de laatse wijzigingen te zien en heel vaak bleek ik een '.' te zijn vergeten (en het is een hel als je dan moet gaan zoeken waar je die punt moet zetten) het ligt niet zo zeer aan m'n editor hoor (die is geweldig) maar aan het lettertype die maar een pixel voor een punt reserveerd.

dan moet je een ander lettertype wellicht overwegen, of je editor instellen dat die concat punt bold gezet word ofzo
Maar als ik een punt vergeet dan krijg ik een "mooie" error van de php engine met daarop het regelnummertje van de fout.

Nog iets waarom je het beter niet zo moet doen is het volgende:

PHP:

$naam = 'Erkens';

echo "Hallo $naam";  // niks "mis" mee :P

echo "Hallo $name"; // oeps per ongeluk verkeerd geschreven, geen error :)

echo 'Hallo ', $naam; // prima
echo 'Hallo ', $name; // sorry een "foutmelding, $name is niet gedefinieerd :)

[PrisonerOfPain]

Erkens schreef op 05 juli 2004 @ 17:07:
dan moet je een ander lettertype wellicht overwegen, of je editor instellen dat die concat punt bold gezet word ofzo

Ik ben nou "{}" gewend, dus waarom zou ik?

Maar als ik een punt vergeet dan krijg ik een "mooie" error van de php engine met daarop het regelnummertje van de fout.

met

PHP:

$var = "foo" . $bar . "foobar" . $barfoo;

Weet je nog niet om welk stuk het ging, daar doelde ik op. Verder ken ik de parse error's van PHP al een flinke tijd hoor ;-)

[Verwijderd]

PHP:

$var = sprintf ( 'foo %s foobar %s',  $bar, $barfoo );

[Erkens]

PrisonerOfPain schreef op 05 juli 2004 @ 17:11:
[...]

Ik ben nou "{}" gewend, dus waarom zou ik?

[...]

met

PHP:

$var = "foo" . $bar . "foobar" . $barfoo;

Weet je nog niet om welk stuk het ging, daar doelde ik op. Verder ken ik de parse error's van PHP al een flinke tijd hoor ;-)

mja, dat neemt nog niet het tweede deel van mijn post weg

Verwijderd schreef op 05 juli 2004 @ 17:14:

PHP:

$var = sprintf ( 'foo %s foobar %s',  $bar, $barfoo );

volgens mij moet ik me hierin eens verdiepen, ziet er een stuk beter uit

[Verwijderd]

Om je nog even een praktischer voorbeeld te geven:

PHP:

printf ( '<a href="product.php?id=%u">%s</a>',
   $product['id'],
   htmlentities ( $product['name'] )
);

[PrisonerOfPain]

Verwijderd schreef op 05 juli 2004 @ 17:14:

PHP:

$var = sprintf ( 'foo %s foobar %s',  $bar, $barfoo );

sprintf gebruik ik eigenlijk alleen als ik meerdere standaard teksten heb waar telkens dezelfde waarde in moet. Dus bijvoorbeeld SQL-Queries tegen een database onafhankelijke class. Op de manier die jij nu voorsteld vind ik het een beetje overkill, PHP heeft operators om het truukje te doen, maar dan ga je een aparte functie gebruiken die hetzelfde doet..

[sjokki]

Na het lezen van deze thread weet ik wel waarom er zoveel brakke php-code is. Php programmeurs houden zich namelijk veel te veel bezig met discussiëren over kleinigheden zoals enkele vs dubbele quotes maar zien ondertussen belangrijke zaken over het hoofd .

Veel code is inderdaad moeilijk te begrijpen als je het niet zelf geschreven hebt. Maar de mensen die het wel geschreven hebben begrijpen het vaak prima omdat ze een bepaald systeem hebben gebruikt.

Een quote van c2:

spaghetti code often is all code that is not our own because it was generated by minds that think differently than us

Dat is op te lossen door met z'n allen op de zelfde manier te programmeren. En dat kan je bereiken door middel van coding standards en het gebruik van een framework.

[PrisonerOfPain]

sjokki schreef op 05 juli 2004 @ 17:36:
Veel code is inderdaad moeilijk te begrijpen als je het niet zelf geschreven hebt. Maar de mensen die het wel geschreven hebben begrijpen het vaak prima omdat ze een bepaald systeem hebben gebruikt.

Of je documenteert het systeem dat je gebruikt, schrijf op waarom je methode x gebruikt ipv methode y, schrijf ontwerp documenten, zeker als je weet dat je publieke code gaat schrijven. Ik heb ook wel eens gehad dat ik m'n eigen code niet meer begreep omdat ik het commentaar was 'vergeten' als je dat is overkomen denk je echt wel een tweede keer om commentaar te vergeten.

[alienfruit]

Hmm, ik hoop dan eigenlijk dat er in PHP5 standaard, de strict-typing functionaliteit aan staat, en de backward compatibility met PHP4 standaard uit. Om zodoende beginners te dwingen.

[PrisonerOfPain]

alienfruit schreef op 05 juli 2004 @ 18:00:
Hmm, ik hoop dan eigenlijk dat er in PHP5 standaard, de strict-typing functionaliteit aan staat, en de backward compatibility met PHP4 standaard uit. Om zodoende beginners te dwingen.

Helaas, de enige manier om 'types' af te dwingen in PHP is met typehints:

PHP:

<?php
class Foo
{
         public function Bar ()
         {
                  echo "FooBar";
         }
}

function BarFoo (Foo $FooFoo)
{
         $FooFoo->Bar();
}
?>

Je kan op die manier dus een class (of interface) afdingen als argument, maar verder als dat gaat het niet.

[stekkel]

crisp schreef op 05 juli 2004 @ 16:50:
[...]

Dit:

PHP:

$var = 'Hallo ' . $naam;

is sneller dan:

PHP:

$var = "Hallo $naam";

Ik gebruik altijd single quotes omdat het zich voorspelbaar gedraagt in alle gevallen.

Dat zou ik niet met stelligheid durven te beweren. Men vergeet namelijk wel eens dat concatenatie van strings ook tijd kost. Het is dus maar de vraag of het voordeel van single quotes bij korte strings opweegt tegen de concatenatie handeling.

[Verwijderd]

stekkel schreef op 05 juli 2004 @ 18:24:

Dat zou ik niet met stelligheid durven te beweren. Men vergeet namelijk wel eens dat concatenatie van strings ook tijd kost. Het is dus maar de vraag of het voordeel van single quotes bij korte strings opweegt tegen de concatenatie handeling.

Benchmark het maar. Concatenation is sneller.

[crisp]

We dwalen wel een beetje af met dat dubbel-quote vs enkel-quote gedoe. Het hele punt is al bewezen door het feit dat er meteen al gevraagd werd wat nou eigenlijk het verschil is. Dat geeft dus al aan dat veel mensen de reference niet doorlezen en/of klakkeloos alles overnemen wat ze aan voorbeeldcode zien.
Alle mensen die hier met goede alternatieven gestaafd met argumenten komen snappen het tenminste, die denken er tenminste over na, en dan maakt het op zich niet uit of je maniertje A of maniertje B gebruikt (het verschil qua performance is natuurlijk nagenoeg nihil) - je weet dan in ieder geval waar je mee bezig bent, en dat is m.i. het belangrijkste

[stekkel]

Verwijderd schreef op 05 juli 2004 @ 18:26:
[...]

Benchmark het maar. Concatenation is sneller.

Je hebt gelijk.

Op php 4.3.6 scheelt het ongeveer 50% en op php 4.2.3 ongeveer 75%.

edit:
Crisp, dat is inderdaad de kern van de zaak

[ Voor 14% gewijzigd door stekkel op 05-07-2004 18:45 ]

[Spruit_elf]

PrisonerOfPain schreef op 05 juli 2004 @ 13:49:
Bij ' worden (bijna) alle waarde's letterlijk genomen (behalve ' en \ geloof ik, die moet je escapen) je kan dus niet zetten '\n' om een newline af te drukken, bij " heb je een hoop meer mogenlijkheden, er zijn meer tekens om te escapen, je kan er variablen in zetten maar het is ook iets trager als '..

als je dan met single quotes geen \n meer kan gebruiken, hoe doen zorgen jullie er dan voor dat de uitgepoepte html een beetje leesbaar is.

zelf vind ik het namelijk erg prettig als de html uiteindelijk ook goed leesbaar is, dat helpt weer bij het opsporen van fouten, en zonder die \n loop het vreeselijk door elkaar.

een oplossing is om het zo tte doen

PHP:

<?
if(!$blaat){
?>
<html>
     <body>
          <p>Hier wat html
          </p>
     </body>
</html>
<?
}
?>

maar als je dan met variabelen wil werken dan wordt het er al helemaal neit beter op

PHP:

<?
if(!$blaat){
$foo = 'html'
?>
<html>
     <body>
          <p>Hier wat <?=$foo?>
          </p>
     </body>
</html>
<?
}
?>

dan is het hier vanwege de shorttags nog te overzien, maar zonder
zelf vind ik dat niet echt een oplossing.
wat is volgens jullie de "netste" methode? om dus zonder "overbodige" php dingen
zoals double quotes met \n (in het geval van geen variabelen)
om dan toch leesbaar html te krijgen? of vinden jullie dat niet erg belangrijk?

[.oisyn]

Verwijderd schreef op 04 juli 2004 @ 20:53:
Zelf heb ik dit lijstje gemaakt met punten waar code aan moet voldoen:
-goed uitbreidbaar -> veel code is niet eenvoudig recyclebaar en hier bedoel ik dan niet mee dat het niet te gebruiken is nadat alles is gecopyenpaste en daarna hier en daar iets is aangepast, maar dat er weinig gebruik wordt gemaakt van classes die weer eenvoudig aangeroepen kunnen worden indien het ergens nodig is. Misschien is OO dus een goeie oplossing.

OO in PHP
Brakke code wordt natuurlijk overal in geschreven, maar in PHP lijkt het toch wel het meest te gebeuren. Nou heeft dat natuurlijk voor een groot deel te maken met de relatief lage drempel om met php overweg te kunnen, anderzijds denk ik dat het ook komt door de taal zelf. Want laten we wel wezen, daar is dus totaal niet over nagedacht

En dan bedoel ik niet dingen als strong-typing; het blijft een scripttaal, en er kan wel degelijk baat zijn bij een loose-typed systeem. Waar ik echter wel een bloedhekel aan heb is hoe met scopes, references en classes omgegaan wordt, dat is gewoon ronduit ranzig. Ik ga het hier niet allemaal nog een keer uitgebreid op tafel leggen, dat heb ik al genoeg gedaan , maar laten ze eerst maar eens een keer een goede taal produceren met een handige feature-set en semantiek waarover nagedacht is, met een bijbehorende consistente, goed opgezette standaard library. Tot die tijd blijft zelfs de netste php code utter crap

[PrisonerOfPain]

mrcactus schreef op 06 juli 2004 @ 02:33:
[...]

als je dan met single quotes geen \n meer kan gebruiken, hoe doen zorgen jullie er dan voor dat de uitgepoepte html een beetje leesbaar is.

HTML echo'en vind ik ook al zo ranzig, maar goed als voorbeeld

PHP:

echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
      <head>
            <title>
                  Blaat
            </title>
      </head>
      <body>
            Test page
      </body>
</html>';

Staat ook in de manual overigens

zelf vind ik het namelijk erg prettig als de html uiteindelijk ook goed leesbaar is, dat helpt weer bij het opsporen van fouten, en zonder die \n loop het vreeselijk door elkaar.

Vind ik ook, het is toch een soort visite kaartje he

een oplossing is om het zo tte doen

PHP:

<?
if(!$blaat){
?>
<html>
     <body>
          <p>Hier wat html
          </p>
     </body>
</html>
<?
}
?>

maar als je dan met variabelen wil werken dan wordt het er al helemaal neit beter op

PHP:

<?
if(!$blaat){
$foo = 'html'
?>
<html>
     <body>
          <p>Hier wat <?=$foo?>
          </p>
     </body>
</html>
<?
}
?>

dan is het hier vanwege de shorttags nog te overzien, maar zonder
zelf vind ik dat niet echt een oplossing.
wat is volgens jullie de "netste" methode? om dus zonder "overbodige" php dingen
zoals double quotes met \n (in het geval van geen variabelen)
om dan toch leesbaar html te krijgen? of vinden jullie dat niet erg belangrijk?

Dat zou ik met alternatieve control structures oplossen, maar het is een manier

.oisyn schreef op 06 juli 2004 @ 02:58:
En dan bedoel ik niet dingen als strong-typing; het blijft een scripttaal, en er kan wel degelijk baat zijn bij een loose-typed systeem. Waar ik echter wel een bloedhekel aan heb is hoe met scopes, references en classes omgegaan wordt, dat is gewoon ronduit ranzig. Ik ga het hier niet allemaal nog een keer uitgebreid op tafel leggen, dat heb ik al genoeg gedaan , maar laten ze eerst maar eens een keer een goede taal produceren met een handige feature-set en semantiek waarover nagedacht is, met een bijbehorende consistente, goed opgezette standaard library. Tot die tijd blijft zelfs de netste php code utter crap

Om je dunk van PHP nog wat op te krikken, ik probeerde laatst de Directory (standaard class die Dir uitwerpt) class uit te breiden omdat ik 'm nogal kaal vond. Standaard heeft de Directory class geen constructor en mist het ook de twee variabele $handle en $path, dat is niet zo erg dat kunnen we oplossen, ik bedacht de volgende constructie:

PHP:

<?php
class myDir extends Directory
{
    private $handle;
    public $path;

    public function __construct ($file)
    {
        $this->handle = opendir (realpath ($file));
    }
}

$D = new myDir ('.');
echo $D->read();
?>

Maar deze gaf een error:

code:

Warning: Directory::read() [function.read]: Unable to find my handle property in
/usr/local/apache2/htdocs/dir.php on line 14

Wat bleek nou (na het doorspitten van de source van PHP, dit staat niet in de manual, blijkbaar) is dat $handle public moet zijn omdat de method's gewoon gemapped worden naar de standaard PHP functies (readdir, rewinddir en closedir) en die kan dus ook niet bij z'n handle op een dergelijke manier...

[creative8500]

PrisonerOfPain: Om je dunk van PHP nog wat op te krikken, [...]

En hoe bewijst PHP zich hier als goede programmeertaal, wat jou betreft?

[PrisonerOfPain]

creative8500 schreef op 06 juli 2004 @ 13:51:
En hoe bewijst PHP zich hier als goede programmeertaal, wat jou betreft?

Was sarcastisch bedoeld ik verbaadse mij er enorm over dat PHP niet ergens in interne mini-class (zodat het voor die class niet uit maakt of die parameter public is of niet) heeft maar het zo oploste.

PHP:

<?php
class Directory
{
        private $handle;
        public $path;

        public function __construct ($path)
        {
                $this->handle = opendir (realpath ($path));
        }

        public function read ()
        {
                return readdir ($this->handle);
        }

        public function close ()
        {
                closedir ($this->handle);
        }

        public function rewind ()
        {
                rewinddir ($this->handle);
        }
}
?>

Zo heb je het voordeel dat het niet uitmaakt of je $handle private maakt of niet en het lijkt me niet zo enorm veel werk (ik moet wel bekennen dat ik weinig kaas heb gegeten van PHP-core devven, maar ik zal het eens onderzoeken ) om na te bootsen. Ipv de IMHO erg gare oplossing die ze nu hebben gekozen..

[whoami]

Apache schreef op 05 juli 2004 @ 15:41:

edit:

@AtleX: woei, graag gedaan
en ACM had een PDF geschreven over beveiling van web applicaties, heb er geen url meer van, maar als hij dit leest wil hij hem misschien nog wel eens posten,

Dat artikel staat in de P&W FAQ.

[Grijze Vos]

mrcactus schreef op 06 juli 2004 @ 02:33:
[...]

als je dan met single quotes geen \n meer kan gebruiken, hoe doen zorgen jullie er dan voor dat de uitgepoepte html een beetje leesbaar is.

Om crisp maar even uit tig andere topics te quoten:

code:

define('CR', "\n");

echo 'blaat'.CR.'blaat';

[ Voor 6% gewijzigd door Grijze Vos op 06-07-2004 14:28 ]

[PrisonerOfPain]

Grijze Vos schreef op 06 juli 2004 @ 14:28:
[...]


Om crisp maar even uit tig andere topics te quoten:

code:

define('CR', "\n");

echo 'blaat'.CR.'blaat';

Het enige nut wat ik daarvan in zie is dat je snel van newline kunt wisselen, anders hoor je IMHO gewoon " te gebruiken hoor, daar is het voor bedoeld.

[Erkens]

PrisonerOfPain schreef op 06 juli 2004 @ 14:34:
[...]

Het enige nut wat ik daarvan in zie is dat je snel van newline kunt wisselen, anders hoor je IMHO gewoon " te gebruiken hoor, daar is het voor bedoeld.

vind ik juist onhandiger, en meer typ werk:

PHP:

echo 'blaat',"\n",'blaat';
// ipv
echo 'blaat',CR,'blaat';

[ Voor 11% gewijzigd door Erkens op 06-07-2004 14:38 ]

[.oisyn]

Mja ik gebruik eigenlijk gewoon altijd double-quotes, aangezien ik dat gewoon gewend ben als C++ programmeur Ik zie eigenlijk geen reden om single-quotes te gebruiken, last van dubbele slashes heb je toch wel. Nou ja goed, dan moet je de $ escapen om die te outputten, maar zo vaak komt dat niet voor, en bovendien kun je dan gelijk gebruik maken van control chars zoals \r en \n

[RwD]

Verwijderd schreef op 05 juli 2004 @ 16:25:
[...]


Als je in je string een $ gebruikt terwijl dat niet nodig is (wanneer je in die string geen variabele gebruikt...) => Dan is single quote sneller.

Dus:

Het maakt qua snelheid pas uit, wanneer je dollartekens gaat gebruiken...
Zolang je geen dollartekens gebruikt, maakt het qua snelheid niets uit... Nou ja iets, want ook \n, \t etc moet geparsed worden

Wat loop je tegen mij dan nog te zeggen dat ik geen gelijk heb als ik beweer dat single quotes sneller zijn? Mijn achterliggende gedachte was dat double quote strings nog geparsed worden, dus zo fout was die gedachte niet gezien de benchmarks na de jouwe....

(Bovendien had ik dit al een hele tijd geleden al eens gelezen in een artikel ik geloof op php.net)

[.oisyn]

Parsen is wat anders, je bedoelt scannen
Single-quoted strings moeten ook gescanned worden, namelijk op slashes. Zo'n scanner wordt meestal gegenereerd uit een lexical analyser generator, wat een O(n) algoritme gebruikt om tekens te vinden. Het aantal verschillende tekens dat gevonden moet worden maakt niet uit, waardoor een string met double quotes en zonder $ dus net zo snel is als een string met single quotes

[Verwijderd]

.oisyn schreef op 06 juli 2004 @ 15:14:
Parsen is wat anders, je bedoelt scannen
Single-quoted strings moeten ook gescanned worden, namelijk op slashes. Zo'n scanner wordt meestal gegenereerd uit een lexical analyser generator, wat een O(n) algoritme gebruikt om tekens te vinden. Het aantal verschillende tekens dat gevonden moet worden maakt niet uit, waardoor een string met double quotes en zonder $ dus net zo snel is als een string met single quotes

En dat komt ook naar voren als je de boel benchmarkt. Zolang je geen dollartekens ongeëscapet gebruikt zijn dubbele quotes net zo snel als enkele quotes.
Ik gebruik zelf bij voorkeur enkele quotes omdat ik dan zonder te escapen dubbele quotes kan gebruiken voor HTML output. Maar als je geen hekel hebt aan escapen kun je inderdaad prima dubbele quotes gebruiken.

[Olaf van der Spek]

mrcactus schreef op 06 juli 2004 @ 02:33:
dan is het hier vanwege de shorttags nog te overzien, maar zonder
zelf vind ik dat niet echt een oplossing.
wat is volgens jullie de "netste" methode? om dus zonder "overbodige" php dingen
zoals double quotes met \n (in het geval van geen variabelen)
om dan toch leesbaar html te krijgen? of vinden jullie dat niet erg belangrijk?

IMO is het totaal niet belangrijk.
Maar met een template engine is de PHP toch wel van de HTML te scheiden op een nette manier?

[megamuch]

Mag ik dan ook even de andere kant op pissen.

Erg veel kritiek hier op PHP omdat het ranzig is, en het niet goed omgaat met references, objecten en weet ik veel wat nog meer.

Like who the f*ck cares??

PHP is een simpele scripting taal met een berg aan functies die je in andere talen zelf zou moeten schrijven.

PHP is snel.
PHP is eenvoudig om te leren.
PHP heeft plenty of built-in functies die erg handig zijn.

En buiten dat, er is een gigantische support voor de taal. Hulp nodig? Check 1 van de 1001 sites over php en je kan je antwoord vaak genoeg wel vinden.

Waar mensen hier vooral aan voorbij gaan is het feit dat ze php willen gebruiken als volwaardige programmeer omgeving. Iets wat 90% van de php scripters niet nodig hebben, laat staan snappen.

Als ik kijk naar mezelf:
ik heb geen idee wat een object is
geen flauw idee wat ik met inheritance moet
public of private? yeah whatever

En toch kan ik met php aardige scripjes schrijven. Simpele websitejes bouwen met zoekmogelijkheden etc. Prima. Class downloaden en gebruiken in m'n scripts wil ook nog wel lukken.

En volgens mij hoor ik tot het merendeel van de php scripters. Die bouwen geen sites voor 100.000 users. Gewoon lekker prutsen en wat leuks bouwen. Iets waar PHP vanaf het begin ook voor bedoelt is. Het is allemaal wat uit de klauwen gegroeid, met een aantal onvolkomenheden. Deal with it.

Als je al die fancy dingen nodig hebt, pak dan .NET / java / <insert random taal> en laat php links liggen.


/end rant

[Verwijderd]

.oisyn schreef op 06 juli 2004 @ 15:14:
Parsen is wat anders, je bedoelt scannen
Single-quoted strings moeten ook gescanned worden, namelijk op slashes. Zo'n scanner wordt meestal gegenereerd uit een lexical analyser generator, wat een O(n) algoritme gebruikt om tekens te vinden. Het aantal verschillende tekens dat gevonden moet worden maakt niet uit, waardoor een string met double quotes en zonder $ dus net zo snel is als een string met single quotes

Amen, dat was dus mijn hele verhaal...

[Olaf van der Spek]

Verwijderd schreef op 04 juli 2004 @ 20:53:
-veilig -> het is al mooi om te zien dat addslashes veel gebruikt wordt (hoewel dit vaak zorgt voor een dubbel addslashes idee omdat standaard magic slash meuk van php aanstaat), maar de veel zo te downloade code is lek.

Maar wat is nou precies DE manier?
Met de magic_quotes_gpc functie is addslashes toch niet meer nodig?

[Janoz]

OlafvdSpek schreef op 06 juli 2004 @ 15:50:
[...]

Maar wat is nou precies DE manier?

PHP:

if (!get_magic_quotes_gpc()) {
   $lastname = addslashes($_POST['lastname']);
} else {
   $lastname = $_POST['lastname'];
}

Dit is de manier waarop het imho in alle te downloade server onafhankelijke voorbeelden zou moeten voorkomen.

[RwD]

.oisyn schreef op 06 juli 2004 @ 15:14:
Parsen is wat anders, je bedoelt scannen
Single-quoted strings moeten ook gescanned worden, namelijk op slashes. Zo'n scanner wordt meestal gegenereerd uit een lexical analyser generator, wat een O(n) algoritme gebruikt om tekens te vinden. Het aantal verschillende tekens dat gevonden moet worden maakt niet uit, waardoor een string met double quotes en zonder $ dus net zo snel is als een string met single quotes

Parsen/scannen, je wist wat ik bedoel. Ik wil nogal snel parsen zeggen terwijl ik vrijwel altijd scannen bedoel (ik werk momenteel met Omnimark, mocht je dat wat zeggen)

Punt is dat je zelf al aangeeft dat een string met dubbele quotes langzamer is. Dat ze ook even snel kunnen zijn doet er niet toe, alle toepassingen meegenomen is een dubbelquote gemiddeld langzamer dan een single quote string, en dus langzamer...

Of niet dan? Anders is een fiat net zo snel als een ferrari, tenzij de fiat een ferrari Enzo is, want een Ferrari valt onder het Fiat concern. <-- die laatste zin hoef je niet letterlijk te nemen, de vergelijking viel tijdens het typen buiten de context.
Ik bedoelde dat twee auto's dan ook even snel zijn, totdat je in eentje een dik persoon met veel dollars zet, die niet in de andere past. In principe ga je dan die persoon altijd in die ene auto proppen, en als iemand anders mee wil kan ie beter in de andere auto gaan zitten, die is meestal sneller...

[Verwijderd]

OlafvdSpek schreef op 06 juli 2004 @ 15:50:
[...]

Maar wat is nou precies DE manier?
Met de magic_quotes_gpc functie is addslashes toch niet meer nodig?

Uit de oude doos:

PHP:

/**
*  Apply magic quotes
*
*  @access public
*  @param  array|string  The input variable
*  @return void
*  @author Jorgen Horstink
*/
function apply_magic_quotes(&$arr)
{
  if (!ini_get('magic_quotes_gpc')) {
    if (is_array($arr)) {
      $c = sizeOf($arr);
      $a = array_keys($arr);
      for ($i = 0; $i < $c; $i++) {
        if (is_array($arr[$a[$i]])) {
          apply_magic_quotes($arr[$a[$i]]);
        } else {
          $arr[$a[$i]] = addslashes($arr[$a[$i]]);
          $arr[$a[$i]] = addslashes($arr[$a[$i]]);
        }
      }
    } elseif (is_string($arr)) {
      $arr = addslashes($arr);
      $arr = addslashes($arr);
    }
  }
}
?>

[ Voor 13% gewijzigd door Verwijderd op 06-07-2004 16:44 ]

[Verwijderd]

RwD schreef op 06 juli 2004 @ 16:01:
[...]
Parsen/scannen, je wist wat ik bedoel. Ik wil nogal snel parsen zeggen terwijl ik vrijwel altijd scannen bedoel (ik werk momenteel met Omnimark, mocht je dat wat zeggen)

Punt is dat je zelf al aangeeft dat een string met dubbele quotes langzamer is. Dat ze ook even snel kunnen zijn doet er niet toe, alle toepassingen meegenomen is een dubbelquote gemiddeld langzamer dan een single quote string, en dus langzamer...

Of niet dan? Anders is een fiat net zo snel als een ferrari, tenzij de fiat een ferrari Enzo is, want een Ferrari valt onder het Fiat concern. <-- die laatste zin hoef je niet letterlijk te nemen, de vergelijking viel tijdens het typen buiten de context.
Ik bedoelde dat twee auto's dan ook even snel zijn, totdat je in eentje een dik persoon met veel dollars zet, die niet in de andere past. In principe ga je dan die persoon altijd in die ene auto proppen, en als iemand anders mee wil kan ie beter in de andere auto gaan zitten, die is meestal sneller...

Absoluut gezien heb je misschien gelijk, maar relatief zijn beide functies even snel. Het is toch logisch dat een functie die meer moet berekenen trager is? De indruk werd alleen gewekt dat het gebruik van dubbele quotes slecht is als je een string gebruikt zonder escape tekens en zonder variabelen. en dát is nou net niet waar.

[Verwijderd]

Janoz schreef op 06 juli 2004 @ 15:59:

PHP:

if (!get_magic_quotes_gpc()) {
   $lastname = addslashes($_POST['lastname']);
} else {
   $lastname = $_POST['lastname'];
}

Dit is de manier waarop het imho in alle te downloade server onafhankelijke voorbeelden zou moeten voorkomen.

Voor beginners is zoiets wel handig, maar ik ben het er niet mee eens. Veel variabelen worden nooit in een query of shell commando gestopt, dus zit je nodeloze slashes toe te voegen.

Ik zie liever dat tutorials aangeven dat je gpc_magic_quotes het best uit kunt zetten en dat je verdomd goed moet begrijpen hoe alles in elkaar zit. Leuk dat PHP oorspronkelijk bedoeld was voor eenvoudige zaken, maar als je nu nog PHP moet leren dan kun je dat het best meteen goed doen. En iedereen die PHP gebruikt zal moeten begrijpen wanneer addslashes nodig is en wanneer niet.

Gevorderden kunnen trouwens zelf wel een database class schrijven die een soort prepared statements kent, en een manier om automatisch tekens uit strings te escapen.

De manier van Jorgen begrijp ik trouwens niet helemaal. Het is niet handig om bepaalde tekens in een string te vervangen door HTML entities.

[.oisyn]

megamuch schreef op 06 juli 2004 @ 15:34:
Mag ik dan ook even de andere kant op pissen.

doe het dan niet tegen de wind in, dan word je nat

Like who the f*ck cares??

Misschien de gevorderde programmeur die naast PHP nog wel wat andere talen kent?

PHP is een simpele scripting taal met een berg aan functies die je in andere talen zelf zou moeten schrijven.

Right, in .Net en Java heb je tenslotte ook geen uitgebreide standaard library, toch?

PHP is snel.

* kuch *

PHP is eenvoudig om te leren.

Dat is geen argument

PHP heeft plenty of built-in functies die erg handig zijn.

Dat hebben andere talen dus ook

En buiten dat, er is een gigantische support voor de taal. Hulp nodig? Check 1 van de 1001 sites over php en je kan je antwoord vaak genoeg wel vinden.

Ja da's misschien leuk voor de beginner, maar de gevorderde heeft ten eerste die hulp niet echt nodig, en ten tweede zijn de voorbeelden die over php op het internet te vinden zijn zo ranzig als mijn kont als ik zojuist gescheten heb

Waar mensen hier vooral aan voorbij gaan is het feit dat ze php willen gebruiken als volwaardige programmeer omgeving. Iets wat 90% van de php scripters niet nodig hebben, laat staan snappen.

Non-argument. Omdat dat voor een groot deel toevallig ook de beginnende programmeurs zijn, wil nog niet zeggen dat dat maar als een excuus gebruikt kan worden om het ranzig te laten. Nergens voor nodig, je kunt best een goede taal opzetten die ook makkelijk te leren is en een handige feature-set heeft. Sommige dingen zijn in PHP gewoon ranzig slecht uitgewerkt omdat daar niet goed over nagedacht is. Als die fouten verbeterd zouden worden dan blijft de taal nog net zo toegankelijk voor iedereen, het wordt alleen wat fijner voor de mensen die wel het voordeel kennen van de andere programmeertalen

ik heb geen idee wat een object is
geen flauw idee wat ik met inheritance moet
public of private? yeah whatever

OO in PHP is sowieso een no-go, dus wat je nu zegt is niet echt relevant. En omdat jij niet weet wat dat allemaal is, moet php maar zo ranzig blijven als het is

En toch kan ik met php aardige scripjes schrijven. Simpele websitejes bouwen met zoekmogelijkheden etc. Prima. Class downloaden en gebruiken in m'n scripts wil ook nog wel lukken.

En wat is nou het punt dat je hiermee wilt maken?

Begrijp me niet verkeerd hoor, ik vind PHP een prima taal voor de klein tot middelmatige projecten, alleen soms zijn er van die dingen waarvan je denkt: ja, had dat nou net even anders gedaan, dan had het veel fijner gewerkt. Het is niet zo dat gezegd wordt dat de hele taal omgegooid moet worden, het zijn gewoon die kleine dingetjes die tot veel irritatie kunnen leiden

Als je al die fancy dingen nodig hebt, pak dan .NET / java / en laat php links liggen.

Waarom? Als je een fiat sneller kan maken (om maar even dat voorbeeld aan te houden ) door 1 boutje aan te draaien, waarom zou je die dan links laten liggen en een ferrari kopen, met alle nadelen van dien (duurder, meer risico, etc.)


.edit:
Wat je dus eigenlijk zegt is dat jij PHP niet ranzig vindt omdat jij niet zo heel veel verstand hebt van programmeren en architectuur, en je dus eigenlijk totaal niet weet waarover je praat, maar toch vind je de dingen die gezegd worden onzin en je vind dat die mensen dan maar een andere programmeertaal moeten gebruiken

[ Voor 6% gewijzigd door .oisyn op 06-07-2004 16:57 ]

[Janoz]

Verwijderd schreef op 06 juli 2004 @ 16:20:
[...]

Voor beginners is zoiets wel handig, maar ik ben het er niet mee eens. Veel variabelen worden nooit in een query of shell commando gestopt, dus zit je nodeloze slashes toe te voegen.

In dat geval wordt het dus:

PHP:

if (get_magic_quotes_gpc()) {
   $lastname = stripslashes($_POST['lastname']);
} else {
   $lastname = $_POST['lastname'];
}

Ik zie liever dat tutorials aangeven dat je gpc_magic_quotes het best uit kunt zetten en dat je verdomd goed moet begrijpen hoe alles in elkaar zit. Leuk dat PHP oorspronkelijk bedoeld was voor eenvoudige zaken, maar als je nu nog PHP moet leren dan kun je dat het best meteen goed doen. En iedereen die PHP gebruikt zal moeten begrijpen wanneer addslashes nodig is en wanneer niet.

Helemaal mee eens. Veel mensen snappen er geen drol van. Ze gebruiken vervolgens speciale tekens en gaan vervolgens de addslashesh methode hierop aanroepen.

$var = addslashes("tekst met " erin");

Die hebben er weinig van begrepen, en ik kan het ze niet kwalijk nemen.

Gevorderden kunnen trouwens zelf wel een database class schrijven die een soort prepared statements kent, en een manier om automatisch tekens uit strings te escapen.

De manier van Jorgen begrijp ik trouwens niet helemaal. Het is niet handig om bepaalde tekens in een string te vervangen door HTML entities.

idd. Het aanpassen van de entities doe ik zelf altijd pas op het moment van afdrukken.

PHP:

<? ?>
<html>
 <head>
  <title><?=html_entity_encode($title)?></title>
  </head>
 <body>
  <?=html_entity_encode($content)?>
 </body>
</html>
  
<? ?>

[pjonk]

Verwijderd schreef op 06 juli 2004 @ 16:20:
Voor beginners is zoiets wel handig, maar ik ben het er niet mee eens. Veel variabelen worden nooit in een query of shell commando gestopt, dus zit je nodeloze slashes toe te voegen.

Mee eens. Net als register_globals, wat in het begin ook heel handig leek, maar bij nader inzien uitnodigde voor gevaarlijke en onduidelijke code.

Ik zie liever dat tutorials aangeven dat je gpc_magic_quotes het best uit kunt zetten en dat je verdomd goed moet begrijpen hoe alles in elkaar zit. Leuk dat PHP oorspronkelijk bedoeld was voor eenvoudige zaken, maar als je nu nog PHP moet leren dan kun je dat het best meteen goed doen. En iedereen die PHP gebruikt zal moeten begrijpen wanneer addslashes nodig is en wanneer niet.

Yep gpc_magic_quotes was in het leven geroepen, omdat er legio programmeurs waarbij het woord escapen niet in hun vocabulair voorkwam.
De meeste hosters hebben deze optie nu gelukkig standaard uitstaan dus zien de programmeurs vanzelf wel de gevolgen

[Verwijderd]

Verwijderd schreef op 06 juli 2004 @ 16:20:
[...]

... knip...

De manier van Jorgen begrijp ik trouwens niet helemaal. Het is niet handig om bepaalde tekens in een string te vervangen door HTML entities.

Ik ben het eens met je verhaal dat eenieder die met PHP begint, goed moet weten waar hij/zij mee bezig is. Maar het virus der luiheid krijgt grip op iedereen.
Vooral programmeurs schijnen nogal vaak lui te zijn.

Waarom ik daar de quote vervang voor een HTML entitie snap ik ook niet. Zoals ik zei: uit de oude doos...
Nou, 't probleem is in ieder geval eenvoudig op te lossen, gewoon entitie vervangen voor \\\".

[Olaf van der Spek]

RwD schreef op 06 juli 2004 @ 16:01:
Punt is dat je zelf al aangeeft dat een string met dubbele quotes langzamer is. Dat ze ook even snel kunnen zijn doet er niet toe, alle toepassingen meegenomen is een dubbelquote gemiddeld langzamer dan een single quote string, en dus langzamer...

Dus?
Als dat verschil inderdaad relevant is, gebruik je een optimizer die geparste 'intermediate code' bijhoudt waarin het verschil tussen enkele en dubbele aanhalingstekens niet meer bestaat.

[Olaf van der Spek]

Verwijderd schreef op 06 juli 2004 @ 16:03:
Uit de oude doos:

Dat is niet equivalent aan de magic quotes functie.

[.oisyn]

RwD schreef op 06 juli 2004 @ 16:01:
Punt is dat je zelf al aangeeft dat een string met dubbele quotes langzamer is.

Dat zeg ik helemaal niet, lees even goed.

Dat ze ook even snel kunnen zijn doet er niet toe, alle toepassingen meegenomen is een dubbelquote gemiddeld langzamer dan een single quote string, en dus langzamer...

Ja en single quotes zijn langzamer als je veel ' tekens in je string wilt hebben
Premature optimisations are the root of all evil, het gebruiken van ' omdat je denkt dat " een stuk langzamer is is gewoon grote onzin. Het scheelt alleen bij gebruik van $, en zelfs dan is de tijdswinst nog minimaal. Gebruik ' dus omdat je veel $ of " wilt gebruiken, of weet ik veel wat voor andere redenen je erbij kunt bedenken, maar het gebruiken omdat het "sneller" is, is gewoon dikke onzin.

[Verwijderd]

OlafvdSpek schreef op 06 juli 2004 @ 16:43:
[...]
Dat is niet equivalent aan de magic quotes functie.

Okey, wou net mijn laatste post updaten, maar de replies schieten uit de grond...

Ik heb die functie even aangepast zodat het wel een equivalent is...

[ Voor 51% gewijzigd door Verwijderd op 06-07-2004 16:46 ]

[.oisyn]

Janoz schreef op 06 juli 2004 @ 15:59:
[...]

PHP:

if (!get_magic_quotes_gpc()) {
   $lastname = addslashes($_POST['lastname']);
} else {
   $lastname = $_POST['lastname'];
}

Dit is de manier waarop het imho in alle te downloade server onafhankelijke voorbeelden zou moeten voorkomen.

Mja, ik vind dat hele magic_quotes_* gedoe enorm ranzig. Het is natuurlijk ten eerste al fout om ervan uit te gaan van een bepaalde setting, dan valt je script meteen bij een herconfig van de server als de setting toevallig wijzigt. That said, waarom zou er dan überhaupt nog een setting zijn die zoiets regelt? En waarom? Alleen maar omdat je iets in een database wil hebben, of als parameter mee wil geven aan een shell commando? Ik heb meestal bovenin de standaard include die ik altijd include gewoon een stukje code staan dat kijkt naar de huidige setting, en als het aan staat dan gaat ie gewoon fijn de quotes verwijderen bij alle $_GET, etc. variabelen. Ook al moet ik ze later weer toevoegen als ik ze in een database wil stoppen, jammer dan. Mijn script werkt tenminste altijd, ongeacht de huidige instelling van magic_quotes_gpc (en runtime zet ik altijd in het script uit). Daarnaast zet ik het natuurlijk wel in een htaccess uit, zodat het zo efficient mogelijk maakt, maar het breekt natuurlijk niet zodra er een setting wijzigt of een htaccess zoek raakt oid

[Olaf van der Spek]

Verwijderd schreef op 06 juli 2004 @ 16:44:
[...]
Okey, wou net mijn laatste post updaten, maar de replies schieten uit de grond...

Ik heb die functie even aangepast zodat het wel een equivalent is...

Nu staat er $v = addslashes(addslashes($v)).

[Verwijderd]

.oisyn schreef op 06 juli 2004 @ 16:51:
[...]


Mja, ik vind dat hele magic_quotes_* gedoe enorm ranzig. Het is natuurlijk ten eerste al fout om ervan uit te gaan van een bepaalde setting, dan valt je script meteen bij een herconfig van de server als de setting toevallig wijzigt. That said, waarom zou er dan überhaupt nog een setting zijn die zoiets regelt? En waarom? Alleen maar omdat je iets in een database wil hebben, of als parameter mee wil geven aan een shell commando? Ik heb meestal bovenin de standaard include die ik altijd include gewoon een stukje code staan dat kijkt naar de huidige setting, en als het aan staat dan gaat ie gewoon fijn de quotes verwijderen bij alle $_GET, etc. variabelen. Ook al moet ik ze later weer toevoegen als ik ze in een database wil stoppen, jammer dan. Mijn script werkt tenminste altijd, ongeacht de huidige instelling van magic_quotes_gpc (en runtime zet ik altijd in het script uit). Daarnaast zet ik het natuurlijk wel in een htaccess uit, zodat het zo efficient mogelijk maakt, maar het breekt natuurlijk niet zodra er een setting wijzigt of een htaccess zoek raakt oid

Je bedoelt zoiets?

PHP:

<?
/** 
*  Apply magic quotes 
* 
*  @access public 
*  @param  array|string  The input variable 
*  @return void 
*  @author Jorgen Horstink 
*/ 
function remove_magic_quotes(&$arr) 
{ 
  if (ini_get('magic_quotes_gpc')) { 
    if (is_array($arr)) { 
      $c = sizeOf($arr); 
      $a = array_keys($arr); 
      for ($i = 0; $i < $c; $i++) { 
        if (is_array($arr[$a[$i]])) { 
          remove_magic_quotes($arr[$a[$i]]); 
        } else { 
          $arr[$a[$i]] = stripslashes($arr[$a[$i]]); 
        } 
      } 
    } elseif (is_string($arr)) { 
      $arr = stripslashes($arr); 
    } 
  } 
}

Ik vind wel dat .oisyn gelijk heeft. Dat hele quotes gebeuren zou gewoon altijd en overal uit moeten staan. Wat zou in vredes naam een reden kunnen zijn om alle quotes te escapen?

OlafvdSpek schreef op 06 juli 2004 @ 16:52:
[...]

Nu staat er $v = addslashes(addslashes($v)).

Ow? Hij doet alleen addslashes als PHP zelf niet automatisch quotes toevoegd...

code:

  // Dit stuk heeft niets met de functie in deze reply te maken, maar
  // met de eerder genoemde apply_magic_quotes
  if (!ini_get('magic_quotes_gpc')) {

Of ben ik nou aan het malen? 'k zit ook al weer veel te lang achter de computer...

[ Voor 16% gewijzigd door Verwijderd op 06-07-2004 17:34 ]

[.oisyn]

Verwijderd schreef op 06 juli 2004 @ 16:55:
Je bedoelt zoiets?

Nou nee meer zoiets

PHP:

function stripslashes_helper (&$v, $k)
{
    if (is_array ($v))
        array_walk ($v, "stripslashes_helper");
    else
        $v = stripslashes ($v);
}

if (get_magic_quotes_gpc ())
{
    if (isset ($_GET))
        array_walk ($_GET, "stripslashes_helper");
    
    if (isset ($_POST))
        array_walk ($_POST, "stripslashes_helper");
    
    if (isset ($_COOKIE))
        array_walk ($_COOKIE, "stripslashes_helper");
    
    if (isset ($_REQUEST))
        array_walk ($_REQUEST, "stripslashes_helper");
}

set_magic_quotes_runtime (0);

[ Voor 6% gewijzigd door .oisyn op 06-07-2004 16:59 ]

[Verwijderd]

array_walk is gewoon een rare functie...

Valt dit ook onder ranzigheid? Een string opgeven als callback functie?

[Erkens]

Verwijderd schreef op 06 juli 2004 @ 17:02:
array_walk is gewoon een rare functie...

niks raars aan, gewoon een handige functie, hoef je zelf het wiel niet uit te vinden

Valt dit ook onder ranzigheid? Een string opgeven als callback functie?

ehm, dat is gewoon de manier waarop je een callback functie doorgeeft in php, in een taal x zal dat op een andere manier zijn, taaleigen dus, niks ranzigs.
Hoewel je het altijd ranzig kan maken door die callback functie via een $_GET te verkrijgen maar iemand met hersens doet dat niet

[.oisyn]

Verwijderd schreef op 06 juli 2004 @ 17:02:
array_walk is gewoon een rare functie...

Argumentatie?

Valt dit ook onder ranzigheid? Een string opgeven als callback functie?

Zie Erkens. Het is nou eenmaal php's manier van function pointers, niets mis mee

[Verwijderd]

Okey, overtuigd... Whow, ging dat even snel

[.oisyn]

Waarom add/stripslash jij 2x

[Verwijderd]

Wederom wil ik tegen de muur aanlopen

/me gaat buiten spelen en komt morgen wel weer terug

[ Voor 97% gewijzigd door Verwijderd op 06-07-2004 17:37 ]

[Olaf van der Spek]

Erkens schreef op 06 juli 2004 @ 17:12:
niks raars aan, gewoon een handige functie, hoef je zelf het wiel niet uit te vinden

Maar waarom tussen quotes?

[Olaf van der Spek]

Verwijderd schreef op 06 juli 2004 @ 16:55:
Ow? Hij doet alleen addslashes als PHP zelf niet automatisch quotes toevoegd...

$arr[$a[$i]] = addslashes($arr[$a[$i]]);
$arr[$a[$i]] = addslashes($arr[$a[$i]]);

[Erkens]

OlafvdSpek schreef op 06 juli 2004 @ 18:18:
[...]

Maar waarom tussen quotes?

lees eens verder

Erkens schreef op 06 juli 2004 @ 17:12:
ehm, dat is gewoon de manier waarop je een callback functie doorgeeft in php, in een taal x zal dat op een andere manier zijn, taaleigen dus, niks ranzigs.

[Olaf van der Spek]

Erkens schreef op 06 juli 2004 @ 18:24:
[...]

lees eens verder

[...]

Maar dat vind ik dus een ranzig 'taaleigen' iets.
Dat het zo moet snap ik wel, de vraag is meer waarom het zo moet.

[ Voor 22% gewijzigd door Olaf van der Spek op 06-07-2004 18:28 ]

[Verwijderd]

Wat jezelf ook kan helpen is het verzinnen van programmeer-richtlijnen. Ik heb mezelf een keer overgehaald er een te verzinnen:
http://rbdata.nl/area51/Programmeer%20richtlijnen.pdf

Toch is dit bestand al niet meer relevant, variabelen zien er nu zo uit:

PHP:

$Pa_KeyValues
$s_Assign

en functies zien er nu zo uit:

PHP:

_get_AssignKeys()
_set_Var()
initialise_Object()

Programmeer richtlijnen zijn niet alleen makkelijk voor jezelf, je hoeft niet elke keer terug te kijken hoe het ook alweer moest, maar het helpt je om constant te programmeren.

Ook als je in team-verband gaat werken en iedereen heeft dezelfde regeltjes om aan te houden werkt het een stuk fijner.

PS. Ik hou dus van perfectionistisch object georiënteerd programmeren (POOP)

[PrisonerOfPain]

PEAR heeft daar ook guidlines voor opgesteld, maar die vind ik (erg) onzinig. Ze gingen (de laatste keer dat ik keek) niet in op de naamgeving van variabelen/functies maar ze hadden het wel over de meest onzinnige dingen over de manier hoe je een if statement op moest schrijven, en dat moest dan met een spatie na het openings haakje en voor het sluithaakje. Over onzinnige dingen gesproken. Ik snap dat er enige consistentie moet zijn maar bepalen waar een spatie moet zijn of niet vind ik _erg_ onzinnig.

[Erkens]

OlafvdSpek schreef op 06 juli 2004 @ 18:26:
[...]

Maar dat vind ik dus een ranzig 'taaleigen' iets.
Dat het zo moet snap ik wel, de vraag is meer waarom het zo moet.

waarom niet? is niks mis mee imo
zo heeft elke taal wel zijn eigen ranzige 'taaleigen' dingen. (voor zover je dit ranzig kan noemen)

[ Voor 10% gewijzigd door Erkens op 06-07-2004 19:19 ]

[PrisonerOfPain]

OlafvdSpek schreef op 06 juli 2004 @ 18:26:
[...]

Maar dat vind ik dus een ranzig 'taaleigen' iets.
Dat het zo moet snap ik wel, de vraag is meer waarom het zo moet.

Het is onorthodox maar dat maakt het nog niet ranzig.

[Verwijderd]

PrisonerOfPain schreef op 06 juli 2004 @ 19:16:
PEAR heeft daar ook guidlines voor opgesteld, maar die vind ik (erg) onzinig. ... if statement op moest schrijven, en dat moest dan met een spatie na het openings haakje en voor het sluithaakje.

Het is dan misschien erg overdreven om na het haakje in de if constructie een spatie te plaatsen, toch is het wel leesbaarder. Zelf doe ik het ook, bekijk het volgende voorbeeld eens en zeg dan welke je leesbaarder vindt.

PHP:

if( isset( $Pa_If[$i_X]['Else']['BeginLine'] ) )

of

PHP:

if(isset($Pa_If[$i_X]['Else']['BeginLine']))

Ik vind het eerste leesbaarder, alleen bij array constructies zoals hierboven beschreven vind het minder leesbaar om daar na de accolades ook een spatie te gebruiken:

PHP:

$Pa_If[$i_X]['Else']['BeginLine']

of

PHP:

$Pa_If[ $i_X ][ 'Else' ][ 'BeginLine' ]

Dus mijn mening is dat je zelf programmeer richtlijnen schrijft die je lekker vind om te gebruiken of die van iemand anders gebruikt die jij goed vind. Het enige wat je dan moet doen is om die aan te houden, en dat is juist moeilijker dan ze schijven.

[ Voor 20% gewijzigd door Verwijderd op 06-07-2004 19:28 ]

[PrisonerOfPain]

Verwijderd schreef op 06 juli 2004 @ 19:27:
Het is dan misschien erg overdreven om na het haakje in de if constructie een spatie te plaatsen, toch is het wel leesbaarder. Zelf doe ik het ook, bekijk het volgende voorbeeld eens en zeg dan welke je leesbaarder vindt.

Ik gebruik zelf altijd

PHP:

if (isSet ($_GET['iets']))
{
//doe gemene dingen
}

Ik ben dat gewend en vind het fijn lezen, maar nuttiger is IMHO om op te schrijven dat je (bijvoorbeeld) alle functie en variabele namen pascal case wilt hebben, de stack voor de needle moet komen en classes camel case gaan, dan heb je tenminste de grote lijnen van consistentie. Om dat over die spaties te gaan lopen mekkeren vind ik (nogmaals) onzinnig, ik bepaal zelf wat ik fijn vind lezen mocht een ander het anders fijn vinden is een code beautifier een mooie uitkomst.

Dus mijn mening is dat je zelf programmeer richtlijnen schrijft die je lekker vind om te gebruiken of die van iemand anders gebruikt die jij goed vind. Het enige wat je dan moet doen is om die aan te houden, en dat is juist moeilijker dan ze schijven.

Inderdaad, maar als het eenmaal gewenning is merk je het niet meer en ziet alles er redelijk consistent uit.

[alienfruit]

Aaah, met Ruben kan ik praten Ik zet zelf ook spaties voor en na een ( ) { } etc. Leest inderdaad fijner.

[PrisonerOfPain]

alienfruit schreef op 06 juli 2004 @ 19:52:
Aaah, met Ruben kan ik praten Ik zet zelf ook spaties voor en na een ( ) { } etc. Leest inderdaad fijner.

http://www.tote-taste.de/X-Project/beautify/

nou leest alles ineens fijn ;-)

[djluc]

Toch wil ik echt even opmerken dat we nu weer over minimale verschillen praten. Deze wegen niet op tegen een degelijk applicatie ontwerp e.d. Maar dat is in het algemeen imo sowieso al veel belangrijker. Om zaken als modulariteit e.d. goed voor elkaar te krijgen is veel meer kennis nodig dan zaken als slashes en spaties tussen haakjes. Over een jaar kan je code met of zonder spaties beter lezen dan code die gewoon niet structureel, in de zin van applicatie ontwerp, is opgebouwd.

[alienfruit]

Ja, maar Applicatieontwerp is wat anders dan de "vormgeving" van de broncode
Ach, blijft altijd lastig dat "software engineering"

[PrisonerOfPain]

djluc schreef op 06 juli 2004 @ 20:03:
Toch wil ik echt even opmerken dat we nu weer over minimale verschillen praten. Deze wegen niet op tegen een degelijk applicatie ontwerp e.d. Maar dat is in het algemeen imo sowieso al veel belangrijker. Om zaken als modulariteit e.d. goed voor elkaar te krijgen is veel meer kennis nodig dan zaken als slashes en spaties tussen haakjes.

Bedankt voor deze post , je hebt me eens aan het denken gezet, want ik zocht al een tijdje een manier om modules/plugins netjes te verzorgen. Het resultaat is een class Install die verdacht veel weg heeft van een Observer pattern.
Iedere module krijgt een register.php welke (duh) alle modules tegen de Install class registreert (de actie om uit te voeren, de bestandsnaam, functie [en class] worden doorgegeven). Het install script doorloopt daarna alle directories opzoek naar een register.php en laat die zijn componenten toevoegen.
Daarna is het relatief simpel om een actie te laten gebeuren, je doorloopt de interne array en include het juiste bestan, roept functies/methode aan die bij de geregistreerde actie hoord.

[Apache]

.oisyn schreef op 06 juli 2004 @ 16:39:
[...]

Ja da's misschien leuk voor de beginner, maar de gevorderde heeft ten eerste die hulp niet echt nodig, en ten tweede zijn de voorbeelden die over php op het internet te vinden zijn zo ranzig als mijn kont als ik zojuist gescheten heb


[...]

Imo gaat het topic ook hierover, t'is zeker niet de taal op zich die zo ranzig is, goed het is niet perfect, dat weten we allemaal maar wie/wat is dat wel.

Het zijn de beginners die hun "wauw ik heb net wat geprogrammeerd en het werkt en het is volgens mij fantastisch dus ik ga het releasen zodat anderen het niet meer moeten doen"-code online gooien welke ontzettend ranzig is geprogrammeerd, net omdat de drempel naar php zo laag is ...

Meestal is de code ook nog niet direct bruikbaar maar moet er eerst een heel deel aan "verhackt" worden voordat ze werkt en daar word ze ook niet meteen beter van, deze code geraakt soms ook opnieuw in circulatie, en soms leren mensen zelfs php aan de hand van die code.

[PrisonerOfPain]

Apache schreef op 06 juli 2004 @ 21:22:
Het zijn de beginners die hun "wauw ik heb net wat geprogrammeerd en het werkt en het is volgens mij fantastisch dus ik ga het releasen zodat anderen het niet meer moeten doen"-code online gooien welke ontzettend ranzig is geprogrammeerd, net omdat de drempel naar php zo laag is ...

Weetje dat ik dat op een manier niet erg vind, je kan namelijk ook die projecten klonen als je niets te doen hebt. Erg ingewikkeld zullen ze niet zijn en dus ben je er ook zo mee klaar. Op alle andere manier heb jij inderdaad gelijk.

[Verwijderd]

Apache schreef op 06 juli 2004 @ 21:22:
[...]
Imo gaat het topic ook hierover, t'is zeker niet de taal op zich die zo ranzig is, goed het is niet perfect, dat weten we allemaal maar wie/wat is dat wel.

Inkoppertje: Haskell, zie mijn sig. voor argumenten. Naja, perfect, it comes close.... Als je je hele leven alleen PHP hebt gezien wordt het denk ik wel een lang reisje voor je het doorhebt...

[Soultaker]

Laten we er geen talendiscussietopic van maken. Het onderwerp van discussie is specifiek PHP en de manier waarop daarin code wordt geschreven.

[djluc]

Er zijn geen standaarden voor het ontwerpen van een app. Behalve dan OOP wat je als echte standaard kunt zien. Dit is echter in PHP4, want in die tijd leven we nog, niet mogelijk. Andere basis-standaarden zijn mij niet echt bekend. Object gebaseerd werken is met een dergelijke scripttaal eigenlijk de enige mogelijkheid. Dit ten opzichte van, ja een simpel voorbeeldje, JavaScript welke ook event-based kan werken.

[Soultaker]

Je kunt in PHP ook procedureel werken. De hele standard library steekt op die manier in elkaar (en op de inconsequente naamgeving na werkt die toch best aardig).

[djluc]

Soultaker schreef op 07 juli 2004 @ 00:38:
Je kunt in PHP ook procedureel werken. De hele standard library steekt op die manier in elkaar (en op de inconsequente naamgeving na werkt die toch best aardig).

Kan je me een voorbeeldje geven hoe je dat dan handig aanpakt? Zeker bij grotere projecten zou het gewoon enorm handig zijn als je goed OOP iets kunt ontwikkelen, maar hoe je procedureel ook een handige opzet kunt maken zie ik niet echt.

[Janoz]

Djluc, je bent van alles door elkaar aan het halen. Procedureel ontwikkelen in php is heel simpel aangezien php een procedurele taal is, net als java een object georienteerde en lisp functionele taal is.

'Standaarden voor het ontwerpen van een app' is absoluut niet het rijtje waar OO in thuis hoort. Hierbij zou ik meer aan frameworks en design patterns denken. Deze zijn legio aanwezig.

En mbt grote projecten procedureel opzetten? Trek de source van linux eens open en kijk hoe dat werkt.

[.oisyn]

Apache schreef op 06 juli 2004 @ 21:22:
Het zijn de beginners die hun "wauw ik heb net wat geprogrammeerd en het werkt en het is volgens mij fantastisch dus ik ga het releasen zodat anderen het niet meer moeten doen"-code online gooien welke ontzettend ranzig is geprogrammeerd, net omdat de drempel naar php zo laag is ...

Daar geef ik je gelijk in, en dat is ook wat ik erkende in mijn eerste post in deze draad ([rml].oisyn in "[ PHP] (te)veel brakke code"[/rml]). Alleen wat ik ook zei is dat wat netheid betreft php sowieso achter blijft op de andere (serieuze) talen (met uitzondering van perl dan ), door al z'n ranzige constructies en onvolkomenheden