Vanwaar het PHP bashen

[Cartman!]

Dit topic is afgesplitst van [alg] Slechtste programmeervoorbeelden deel 4


Weer lekker makkelijk op PHP bashen zo te zien zoals vaker gebeurt hier... Er wordt vaak gegrepen naar hoe andere talen dit dan geweldig opgelost hebben maar who gives a f*ck als je alleen in PHP werkt nu? Ik zeg daarmee niet dat ik niet achter alle keuzes sta van de PHP devvers maar het is eenmaal geen .NET. Als jij overtuigt bent dat PHP zuigt en ASP.NET helemaal de bom is gebruik je dat toch lekker

Er is niemand die je verplicht bepaalde features te gebruiken of om uberhaupt die taal te gebruiken als het je niet aanstaat.

[ Voor 9% gewijzigd door Janoz op 27-03-2009 17:21 ]

[.oisyn]

En tevens is er ook niemand die je verbiedt hier te zeiken op PHP. Dus als je overtuigd bent dat dat je leven wat dragelijker maakt, dan doe je dat toch lekker . Wat is er, voel je je op je pik getrapt omdat jij er wel per se in moet werken?

Sebazzz schreef op donderdag 26 maart 2009 @ 18:18:
[...]
Dat denk ik soms ook. Ik vind dat Microsoft met de Visual Studio/.NET combinatie een ijzersterk ontwikkelplatform in handen heeft, dus PHP is inderdaad een zinkend schip wat dat betreft.
.NET is sterk, vooral omdat heel veel talen zijn te '.NETten'. C#.NET, VB.net, Python.NET, A#.NET, Ruby.NET, Delphi.NET. Hiermee kan je heel veel programmeurs aantrekken, en met de sterke debugger van VS maak je het ontwikkelen ook nog eens leuk

En PHP.Net... Voor als je .Net wilt ontwikkelen maar niet zonder de perversies kan die PHP je biedt

[ Voor 71% gewijzigd door .oisyn op 26-03-2009 19:11 ]

[MBV]

@Cartman!: soms worden ook wij, PHP-bashers, gedwongen om onderhoud te plegen aan uit hun krachten gegroeide PHP-websites

[Cartman!]

@ .oisyn: niet zozeer op mn pik getrapt maar soms is het wel erg makkelijk en wordt er naar mijn idee gedacht dat *iedereen* die met PHP werkt een prutser is.

@MBV: tja, dan bouw je het toch opnieuw in de taal die jij superieur vind? Ik kan er niks aan doen dat jouw collega's blijkbaar niet goed kunnen programmeren.

Dat $array[key] een notice oplevert betekent niet dat iedereen dat ook doet natuurlijk, je kunt t zo netjes maken als je zelf wilt.

[.Gertjan.]

Cartman! schreef op donderdag 26 maart 2009 @ 18:40:
Weer lekker makkelijk op PHP bashen zo te zien zoals vaker gebeurt hier... Er wordt vaak gegrepen naar hoe andere talen dit dan geweldig opgelost hebben maar who gives a f*ck als je alleen in PHP werkt nu? Ik zeg daarmee niet dat ik niet achter alle keuzes sta van de PHP devvers maar het is eenmaal geen .NET. Als jij overtuigt bent dat PHP zuigt en ASP.NET helemaal de bom is gebruik je dat toch lekker

Er is niemand die je verplicht bepaalde features te gebruiken of om uberhaupt die taal te gebruiken als het je niet aanstaat.

Och, over .NET kun je ook slechte dingen zeggen (platform onafhankelijk anyone?). Echter is het wel zo dat de support base voor .NET best groot is. Vooral in de zakelijke wereld. PHP wordt ook gebruikt, maar in de bedrijfswereld komt .NET denk ik vaker voor. En ik denk dat bedrijven ook waarde hechten aan de naam Microsoft. Ik weet niet of er voor PHP opleidingstrajecten zijn, maar voor .NET kun je je MCTS halen om te bewijzen dat je het kunt. PHP heeft bij velen gewoon de status van een hobby taal. Daar kun je vrij weinig aan doen vrees ik.

Ik vind niet echt dat er gebashed wordt. Er zijn gewoon beperkingen in PHP.Als je niet tegen kritiek over een taal kunt heb je net zo goed tunnelvisie als dat je de taal zou afkraken omdat een andere taal beter is.

En wat sebazzz al aangeeft dat je binnen .NET met diverse talen kunt werken die op het zelfde framework draaien. Ook is het fijn dat je met 1 framework en taal meerdere soorten applicaties kunt maken. Ik zie in PHP nog geen windows service geschreven worden . En Visual Studio is een zeer krachtige tool met fatsoenlijke codecompletion en debugging opties.

Tussen de .NET talen zitten ook minder prettige talen. Zo vind ik VB.NET nou niet echt fijn, maar dat is vooral omdat een aantal dingetjes niet kunnen in VB.NET (zoals een statement over meerdere regels spreiden moet in VB met _ en je kunt geen strings over meerdere regels spreiden zoals in C# met het @ symbool kan. Ook is VB.NET niet typesafe in de variabelen die je tegen een functie aangooit. Sommige vinden dat fijn, maar ik vind dat je zo vrij enge code krijgt, want er wordt niet altijd gekeken naar wat er binnenkomt).

Ik moet toegeven dat ik voorbeeld dat Hacku geeft

PHP:

<?php
function blaat ()
{
    return array ( 'test', 'test2' );
}

echo blaat()[0]; // werkt niet

$temp = blaat();
echo $temp[0]; // werkt wel
?>

in mijn ogen getuigt dat PHP sommige dingen raar/beperkt oplost. In principe moet je direct met de variabele kunnen werken (eventueel met een cast indien nodig). En het is gewoon spijtig dat PHP dit niet kan.

Maar goed ieder zijn voorkeur. Toen ik van ASP naar PHP ging was dat een opluchting, toen ik daarna .NET ging doen was ik verkocht en wil ik niet meer terug.

Ik denk dat de discussie/oorlog .NET <-> PHP wel vaker gevoerd is op GoT.

[Verwijderd]

JAVA !!!!!!1111oneoneone

[Verwijderd]

Verwijderd schreef op donderdag 26 maart 2009 @ 19:57:
JAVA !!!!!!1111oneoneone

Java is leuk, maar qua GUI design valt het een beetje tegen. Wegens zware crossplatformheid is daar geen echte standaard voor, dus is het altijd een beetje aankloten met editors en dependencies.

Verder heeft iedereen qua taal natuurlijk zijn voorkeuren, en heeft elke taal zijn eigen set voor- en nadelen...maar dat is helemaal niet interessant voor dit topic.

[XWB]

Ik moet toegeven dat ik voorbeeld dat Hacku geeft in mijn ogen getuigt dat PHP sommige dingen raar/beperkt oplost. In principe moet je direct met de variabele kunnen werken (eventueel met een cast indien nodig). En het is gewoon spijtig dat PHP dit niet kan.

PHP kent nog veel gekke gebreken

PHP:

$data = array ( 5, 8, 9, 2, 7 ); // persoonlijk wil ik ook zoiets mogelijk zien: $data = [];

foreach ( $data as $row )
{
    // doe iets
}

var_dump ( $row ); // 7

$row is beschikbaar buiten de scope.

[Koppensneller]

Verwijderd schreef op donderdag 26 maart 2009 @ 20:10:
[...]

Java is leuk, maar qua GUI design valt het een beetje tegen. Wegens zware crossplatformheid is daar geen echte standaard voor, dus is het altijd een beetje aankloten met editors en dependencies.

Leuke quote over het feit dat sommigen Java goed vinden omdat het cross-platform is:

Saying Java is good because it's cross-platform, is like saying you like anal sex because it works on all genders.

[XWB]

Leuke quote over het feit dat sommigen Java goed vinden omdat het cross-platform is:

Waarbij 90% van de Java ontwikkelaars nooit voor meer dan één platform ontwikkeld

[Koppensneller]

Hacku schreef op donderdag 26 maart 2009 @ 20:19:
[...]


Waarbij 90% van de Java ontwikkelaars nooit voor meer dan één platform ontwikkeld

Ja maar, het zóu toch kunnen!

[Verwijderd]

Verwijderd schreef op donderdag 26 maart 2009 @ 20:10:
[...]

Java is leuk, maar qua GUI design valt het een beetje tegen. Wegens zware crossplatformheid is daar geen echte standaard voor, dus is het altijd een beetje aankloten met editors en dependencies.

PHP heeft natuurlijk wel een GUI-standaard... Sterker nog, de meeste programma's worden met C en C++ geschreven. Daar is ook geen GUI-standaard voor.

Je kan met C, C++, Java en PHP gewoon alle mogelijke GUI libraries aanroepen die er zijn. Java heeft ook nog zijn eigen ingebouwde Swing en SWT, maar dat wil je eigenlijk alleen gebruiken als cross-platform er toe doet inderdaad.

[AtleX]

Hacku schreef op donderdag 26 maart 2009 @ 20:14:
[...]


PHP kent nog veel gekke gebreken

PHP:

$data = array ( 5, 8, 9, 2, 7 ); // persoonlijk wil ik ook zoiets mogelijk zien: $data = [];

Bedoel je met je comment dat je een lege array wilt aanmaken? Gewoon $data = array() voldoet dan.

[XWB]

AtleX schreef op donderdag 26 maart 2009 @ 20:29:
[...]

Bedoel je met je comment dat je een lege array wilt aanmaken? Gewoon $data = array() voldoet dan.

Dat weet ik Ik bedoel dat ik zoiets mogelijk wil zien:

PHP:

$data = [];

$data2 = [ 1, 4, 7, 9 ];

Verwijderd schreef op donderdag 26 maart 2009 @ 20:10:
[...]

Java is leuk, maar qua GUI design valt het een beetje tegen. Wegens zware crossplatformheid is daar geen echte standaard voor, dus is het altijd een beetje aankloten met editors en dependencies.

Verder heeft iedereen qua taal natuurlijk zijn voorkeuren, en heeft elke taal zijn eigen set voor- en nadelen...maar dat is helemaal niet interessant voor dit topic.

Mja, de GUI. Mijn voorkeur ging altijd voor .Net, ook omdat er geen enkele Java IDE aan Visual Studio kan tippen (mijn mening, laat de Java fans maar aanvallen ).

[ Voor 49% gewijzigd door XWB op 26-03-2009 20:34 ]

[.Gertjan.]

Hacku schreef op donderdag 26 maart 2009 @ 20:14:
[...]


PHP kent nog veel gekke gebreken

PHP:

$data = array ( 5, 8, 9, 2, 7 ); // persoonlijk wil ik ook zoiets mogelijk zien: $data = [];

foreach ( $data as $row )
{
    // doe iets
}

var_dump ( $row ); // 7

$row is beschikbaar buiten de scope.

Dat scoping geeft in sommige talen ook rare dingen:

code:

if(true) {
 int i = 5;
}

int i = 6;

Sommige talen/compilers klappen er dan in bij

code:

 int i = 6;

het ombouwen naar uit met de melding dat i al bestaat.

Ombouwen naar

code:

 i = 6;

geeft de melding dat i niet gedefinieerd is.

Ik geloof dat dit in oudere versies van Java gebeurde. Uiteraard is het niet goed om code als bovenstaand te schrijven (variabele namen recyclen), maar dit is me tijdens mijn studie opgevallen in Java.

(Kan zijn dat ik er naast zit hoor, maar er was iets met die scoping)

[ Voor 13% gewijzigd door .Gertjan. op 26-03-2009 20:37 . Reden: Hacku reageerde zelf al ]

[Verwijderd]

Hacku schreef op donderdag 26 maart 2009 @ 20:33:
Mja, de GUI. Mijn voorkeur ging altijd voor .Net, ook omdat er geen enkele Java IDE aan Visual Studio kan tippen (mijn mening, laat de Java fans maar aanvallen ).

Visual Studio draait niet onder Linux, da's een makkelijke keuze voor mij.

[XWB]

Verwijderd schreef op donderdag 26 maart 2009 @ 20:39:
[...]

Visual Studio draait niet onder Linux, da's een makkelijke keuze voor mij.

Ja, dan houdt het natuurlijk op

[Morax]

.Gertjan. schreef op donderdag 26 maart 2009 @ 20:36:
[...]


Dat scoping geeft in sommige talen ook rare dingen:

code:

if(true) {
 int i = 5;
}

int i = 6;

Sommige talen/compilers klappen er dan in bij

code:

 int i = 6;

het ombouwen naar uit met de melding dat i al bestaat.

Ombouwen naar

code:

 i = 6;

geeft de melding dat i niet gedefinieerd is.

Ik geloof dat dit in oudere versies van Java gebeurde. Uiteraard is het niet goed om code als bovenstaand te schrijven (variabele namen recyclen), maar dit is me tijdens mijn studie opgevallen in Java.

(Kan zijn dat ik er naast zit hoor, maar er was iets met die scoping)

Natuurlijk is er een probleem, de variabele wordt geïnitialiseerd of niet aan de hand van een conditie, en na die conditie ga je hem nog eens bewerken. De compiler detecteerd dan (terecht) dat er een situatie kan optreden waarbij je een variabele bewerkt die nog niet geïnitialiseerd is

[Megamind]

Al vond ik het magisch typecasten van PHP in het begin wel handig, maar als je er wat dieper inzit dan zou het voor PHP toch prettiger zijn om je variables vooral te kunnen casten, teminste het kan nu ook al, maar heeft niet veel nut.

[Verwijderd]

Verwijderd schreef op donderdag 26 maart 2009 @ 20:28:
[...]

PHP heeft natuurlijk wel een GUI-standaard... Sterker nog, de meeste programma's worden met C en C++ geschreven. Daar is ook geen GUI-standaard voor.

Je kan met C, C++, Java en PHP gewoon alle mogelijke GUI libraries aanroepen die er zijn. Java heeft ook nog zijn eigen ingebouwde Swing en SWT, maar dat wil je eigenlijk alleen gebruiken als cross-platform er toe doet inderdaad.

Klopt inderdaad wel, maar in mijn hoofd maakte ik de vergelijking met bijv. de Visual Studio GUI designer...die vind ik heerlijk werken.

Hacku schreef op donderdag 26 maart 2009 @ 20:33:
[...]


Dat weet ik Ik bedoel dat ik zoiets mogelijk wil zien:

PHP:

$data = [];

$data2 = [ 1, 4, 7, 9 ];

Wat is precies het verschil dan, behalve syntax ( array( .. ) of [ .. ] ) ?

[...]


Mja, de GUI. Mijn voorkeur ging altijd voor .Net, ook omdat er geen enkele Java IDE aan Visual Studio kan tippen (mijn mening, laat de Java fans maar aanvallen ).

Een IDE is natuurlijk meer dan alleen een GUI designer...en wat betreft overige functionaliteit (eventueel uitbreidbaar met plugins) vind ik persoonlijk Eclipse vrijwel gelijkwaardig aan Visual Studio.
Alleen werkt Eclipse over het algemeen wat langzamer/logger...

[ Voor 19% gewijzigd door Verwijderd op 26-03-2009 21:00 ]

[XWB]

Megamind schreef op donderdag 26 maart 2009 @ 20:51:
Al vond ik het magisch typecasten van PHP in het begin wel handig, maar als je er wat dieper inzit dan zou het voor PHP toch prettiger zijn om je variables vooral te kunnen casten, teminste het kan nu ook al, maar heeft niet veel nut.

Hier kan php ook leuke dingen met doen.

PHP:

$t = '6_test';

echo (int) $t; // 6

Wat is precies het verschil dan, behalve syntax ( array( .. ) of [ .. ] ) ?

Niks, alleen de korte syntax. In andere talen / scripts ben ik ook een korte syntax gewoon.

[ Voor 16% gewijzigd door XWB op 26-03-2009 20:59 ]

[.Gertjan.]

Morax schreef op donderdag 26 maart 2009 @ 20:45:
[...]


Natuurlijk is er een probleem, de variabele wordt geïnitialiseerd of niet aan de hand van een conditie, en na die conditie ga je hem nog eens bewerken. De compiler detecteerd dan (terecht) dat er een situatie kan optreden waarbij je een variabele bewerkt die nog niet geïnitialiseerd is

De variabele zou in mijn ogen alleen binnen de if bestaan en daarna vervallen. Het eerste stukje code zou moeten werken omdat na de if de i niet meer bestaat en je hem dus logischerwijs gaat aanmaken. Dat je hem niet aan kan roepen is logisch, want je verwacht dat hij alleen binnen de if bestaat en buitenste if aanroepen zou onlogisch zijn.

Maar ik verbaasde me erover dat hij eerst aangeeft dat i al bestaat (eerste versie) en niet opnieuw gedeclareerd kan worden, als je dan de i gaat gebruiken zonder hem te declareren (2de versie) geeft de compiler aan dat hij niet bekend is (dus de 2 meldingen zijn tegenstrijdig).

Zover ik weet gaan dingen die binnen bijvoorbeeld een for, while of if worden aangemaakt komen te vervallen na dat stuk. Of zit ik er naast. Ik weet van een for dat wat in het for deel zelf staat na de for vervalt. Je kan namelijk dit doen:

C#:

for(int i = 0; i < 1; i++) {
}

for(int i=1; i < 2; i++) {
}

dus ik verwacht dat alle declaraties binnen de for ook vervallen na de for.
Maar goed mijn ervaring met Java is (gelukkig ) al weer enkele jaren oud. (Hoewel ik nu ook weer voor een project een oud systeem gemaakt in Java aan het mishan.. onderhouden ben).

[XWB]

Zover ik weet gaan dingen die binnen bijvoorbeeld een for, while of if worden aangemaakt komen te vervallen na dat stuk. Of zit ik er naast.

Ja, behalve in php. Dan bestaat i nog buiten de scope.

[Michali]

Hacku schreef op woensdag 25 maart 2009 @ 23:39:
Ik droom nog steeds van deze constructie:

PHP:

function blaat ()
{
    return array ( 'test', 'test2' );
}

echo blaat()[0]; // werkt niet

$temp = blaat();
echo $temp[0]; // werkt wel

Dit komt binnenkort. Kan het even niet terugvinden alleen.


Hier nog meer leuke features van PHP

PHP:

<?php

$test = '0';
var_dump(empty($test));
//bool (true)

$test1 = '012345';
$test2 = '12345';
var_dump($test1 == $test2);
//bool (true)

?>

[Megamind]

Hacku schreef op donderdag 26 maart 2009 @ 20:33:
[...]


Dat weet ik Ik bedoel dat ik zoiets mogelijk wil zien:

PHP:

$data = [];

$data2 = [ 1, 4, 7, 9 ];

Zowiezo kan je in PHP ook gewoon

PHP:

$array[] = 'val';

doen.

Michali schreef op donderdag 26 maart 2009 @ 21:06:
[...]

PHP:

<?php
$test1 = '012345';
$test2 = '12345';
var_dump($test1 == $test2);
//bool (true)

?>

Daarvoor hebben ze ook === uitgevonden Dat kom je niet vaak tegen in andere talen.

Dit vindt ik dan wel weer een erg nutteloze constructie die je snel over het hoofd ziet:

PHP:

$a = 2;
if ($a = 3)
  echo 'ja!';
//zal altijd true zijn, zou gewoon een warning moeten geven.

[ Voor 47% gewijzigd door Megamind op 26-03-2009 21:11 ]

[XWB]

Michali schreef op donderdag 26 maart 2009 @ 21:06:
[...]

Dit komt binnenkort. Kan het even niet terugvinden alleen.

In welke versie, 6 ?

Hier nog meer leuke features van PHP

PHP:

<?php

$test = '0';
var_dump(empty($test));
//bool (true)

$test1 = '012345';
$test2 = '12345';
var_dump($test1 == $test2);
//bool (true)

?>

Ja, logica is soms ver te zoeken De strings worden als integer behandeld. Geen probleem als je php kent, maar toen ik jaren terug begonnen ben met php heb ik wel eens lopen vloeken.

Daarvoor hebben ze ook === uitgevonden Dat kom je niet vaak tegen in andere talen.

Dan nog is het niet logisch String casten naar integer.

Dit vindt ik dan wel weer een erg nutteloze constructie die je snel over het hoofd ziet:

$a wordt gewoon 3? Een warning zou hier wel op zijn plaats zijn.

[ Voor 20% gewijzigd door XWB op 26-03-2009 21:14 ]

[Michali]

Megamind schreef op donderdag 26 maart 2009 @ 21:07:
Daarvoor hebben ze ook === uitgevonden Dat kom je niet vaak tegen in andere talen.

Snap ik, maar waarom, in vredesnaam, worden de waardes gecast naar een int als ik 2 strings vergelijk? Ik weet dat ik daarvoor eigenlijk strcmp moet gebruiken, maar ik vind het toch maar vreemd.

[.Gertjan.]

Megamind schreef op donderdag 26 maart 2009 @ 21:07:
[...]

Zowiezo kan je in PHP ook gewoon

PHP:

$array[] = 'val';

doen.

[...]

Daarvoor hebben ze ook === uitgevonden Dat kom je niet vaak tegen in andere talen.

Ik dacht altijd dat === een geintje was. Op die manier zou je zeker weten dat het gelijk is. Weer wat geleerd.

PHP:

<?php
$test1 = '012345';
$test2 = '12345';
var_dump($test1 == $test2);
//bool (true)

?>

Vind ik heel eng. Dit is leuk voor hele getallen. Als je met decimalen gaat werken gaat dit mis. Want wanneer is het een punt en wanneer een komma. Als je dan waardes bij elkaar op gaat tellen zou het soms mis gaan.

In Javascript kan dit ook. Alleen heb ik het daar wel eens meegemaakt dat Javascript besloot om er toch maar een string van te maken en mijn optelsom dus beide getallen als string ging behandelen (en dat gebeurde maar in 1 browser), toen werd 10 + 10 -> 1010. Erg vervelend. Dus sindsdien programmeer ik in javascript voor de zekerheid een parseInt(x,10) eromheen (en de 10 zet ik er bij omdat ik ook ooit mee heb gemaakt dat de browser op de een of andere manier een base 8 of 16 ging gebruiken).

[Michali]

Hacku schreef op donderdag 26 maart 2009 @ 21:11:
In welke versie, 6 ?

Dit was het:

http://wiki.php.net/rfc/functionarraydereferencing

Geen idee of het ook daadwerkelijk geïmplementeerd gaat worden.

[ Voor 15% gewijzigd door Michali op 26-03-2009 21:18 ]

[XWB]

Ik dacht altijd dat === een geintje was. Op die manier zou je zeker weten dat het gelijk is. Weer wat geleerd.

=== gebruik ik het meest bij booleans.

PHP:

$t = 'true';
$b = true;

var_dump ( $t == $b ); // true \o/
var_dump ( $t === $b ); // false

Michali schreef op donderdag 26 maart 2009 @ 21:17:
[...]

Dit was het:

http://wiki.php.net/rfc/functionarraydereferencing

Geen idee of het ook daadwerkelijk geïmplementeerd gaat worden.

Dat is inderdaad wat we willen, maar:

Date: June 16, 2008
Status: Information Gathering

Ik reken er niet op.

[ Voor 41% gewijzigd door XWB op 26-03-2009 21:22 ]

[.oisyn]

Cartman! schreef op donderdag 26 maart 2009 @ 19:18:
@ .oisyn: niet zozeer op mn pik getrapt maar soms is het wel erg makkelijk en wordt er naar mijn idee gedacht dat *iedereen* die met PHP werkt een prutser is.

Ik vind dat maar een heel rare redenatie, dat als je het over de tekortkomingen hebt over de taal PHP en haar designteam dat je dan meteen PHP'ers als prutser afschildert . Blijkbaar ben je dus wél op je pik getrapt, anders trek je dat soort conclusies niet. Lijkt mij dan iig

[ Voor 11% gewijzigd door .oisyn op 26-03-2009 21:24 ]

[Michali]

Hacku schreef op donderdag 26 maart 2009 @ 21:18:
Dat is inderdaad wat we willen, maar:

Date: June 16, 2008
Status: Information Gathering

Ik reken er niet op.

Hmm, het zit wel in onderdeel "In The Works", dus wellicht dat er nog wel wat mee gedaan wordt. Staan overigens nog best wel grappige dingen in die RFC's. Mooi dat upload progress eindelijk eens beschikbaar wordt. En closures, lambda functies, en de mogelijk om functies als parameter mee te geven, daar ben ik wel blij mee.

[MadEgg]

Megamind schreef op donderdag 26 maart 2009 @ 21:07:
Dit vindt ik dan wel weer een erg nutteloze constructie die je snel over het hoofd ziet:

PHP:

$a = 2;
if ($a = 3)
  echo 'ja!';
//zal altijd true zijn, zou gewoon een warning moeten geven.

Dat is toch niet raar dat dat geen warning oplevert? Is gewoon valide code. In deze constructie wellicht ietwat nutteloos, maar ik gebruik wel regelmatig dit soort constructies. Voorbeeld:

PHP:

if ($result = mysql_query($query))
{
    // Hier weet je dat de query gelukt is en is het resultaat ook gelijk beschikbaar
}

Syntactueel gezien is dat natuurlijk precies hetzelfde maar in dit geval heeft wel wel zin. Dus dat er daarvoor geen warning gesproeid wordt is niet zo raar vindt ik.

[.oisyn]

Hacku schreef op donderdag 26 maart 2009 @ 21:04:
[...]


Ja, behalve in php. Dan bestaat i nog buiten de scope.

PHP kent gewoon geen block scoping. Daar is an sich niet zo heel veel mis mee, en er zijn wel meer talen die dat niet doen (bijv. C en Javascript). Wat dan wel weer erg vervelende effecten kan hebben:

PHP:

$a = array(1, 2, 3);
foreach($a as &$v) { }
foreach($a as $v) { }
print_r($a);

Array
(
    [0] => 1
    [1] => 2
    [2] => 2
)

Woei

[XWB]

Daar is an sich niet zo heel veel mis mee,

Neen, maar dat kan - zoals je zelf zegt - erg vervelend zijn. Het voorbeeld dat je aangeeft heb ik ooit lang op lopen debuggen, en ik maar zoeken wat ik verkeerd deed

[Megamind]

MadEgg schreef op donderdag 26 maart 2009 @ 21:36:
[...]


Dat is toch niet raar dat dat geen warning oplevert? Is gewoon valide code. In deze constructie wellicht ietwat nutteloos, maar ik gebruik wel regelmatig dit soort constructies. Voorbeeld:

PHP:

if ($result = mysql_query($query))
{
    // Hier weet je dat de query gelukt is en is het resultaat ook gelijk beschikbaar
}

Syntactueel gezien is dat natuurlijk precies hetzelfde maar in dit geval heeft wel wel zin. Dus dat er daarvoor geen warning gesproeid wordt is niet zo raar vindt ik.

Ja ok, maar dan vergelijk je ook geen variable met een constante, maar de return value van een functie.

In andere talen bv Pascal bestaat er maar 1 soort =.

Delphi:

if Var = false then
showmessage('false')

PHP zal doodleuk van Var false maken.

[.oisyn]

Duh, C#, C, C++ en Java ook. Wat is je punt? C-like talen gebruiken een = voor de assignment en de == voor vergelijking. Pascal gebruikt een := voor assignment en = voor vergelijking (en kent dus niet maar "1 soort ="). In VB heb je wel alleen maar een = voor zowel de assignment als de vergelijking.

[ Voor 24% gewijzigd door .oisyn op 26-03-2009 21:48 ]

[Tanuki]

Megamind schreef op donderdag 26 maart 2009 @ 21:07:
[...]

Dit vindt (Foei!) ik dan wel weer een erg nutteloze constructie die je snel over het hoofd ziet:

PHP:

$a = 2;
if ($a = 3)
  echo 'ja!';
//zal altijd true zijn, zou gewoon een warning moeten geven.

In dit geval wel, als je in plaats van 3 te assignen, 0 zou assignen, zou het false opleveren.

Je kijkt namelijk niet "of de toekenning lukt", maar wat de waarde is van $a. Dat is 3 en dat evalueert naar true.

[ Voor 16% gewijzigd door Tanuki op 26-03-2009 21:50 ]

[.Gertjan.]

Megamind schreef op donderdag 26 maart 2009 @ 21:41:
[...]

Ja ok, maar dan vergelijk je ook geen variable met een constante, maar de return value van een functie.

In andere talen bv Pascal bestaat er maar 1 soort =.

Delphi:

if Var = false then
showmessage('false')

PHP zal doodleuk van Var false maken.

Dat los je dan ook op door te zeggen if(!Var)

Maar VB(.NET) heeft dat ook, die gebruikt voor toewijzing en vergelijking dezelfde =. Op zich wel handig, maar als je terug gaat naar C# en je zegt iets als: if(var = 1) { } krijg je volgens mij een compiler error (of warning, maar ik geloof een error).

Ik vind het maar verwarrend dat je in verschillende talen verschillende soorten = gebruikt (VB en SQL hebben ook nog een IS, die gebruik je voor Nothing (VB) of Null (SQL) vergelijkingen). Delphi/Pascal gebruikt voor toekenning weer de notatie :=

Als ik veel switch tussen C# en VB of SQL dan gaat het af en toe mis met = / == / IS (en Nothing die werkt als null voor VB.NET).

Ik heb wel eens de tip gekregen om in plaats van

C#:

if ( x == 5) { }

gebruikt te maken van

C#:

if (5 == x) { }

Mocht je in een taal die het toewijzen in de if toestaat een = vergeten krijg je een error omdat je x niet aan de constante 5 mag toekennen.

[XWB]

Michali schreef op donderdag 26 maart 2009 @ 21:24:
[...]

Hmm, het zit wel in onderdeel "In The Works", dus wellicht dat er nog wel wat mee gedaan wordt. Staan overigens nog best wel grappige dingen in die RFC's. Mooi dat upload progress eindelijk eens beschikbaar wordt. En closures, lambda functies, en de mogelijk om functies als parameter mee te geven, daar ben ik wel blij mee.

We zien wel, ik hoop iig dat het er komt. PHP 5.3 vermeldt nog niks, dus het wordt ten vroegste PHP 6.

[Sebazzz]

@GertJan: Waarom zou je tussen VB en C# switchen, want het is een compleet andere syntax (die ik niet kan doorzien overigens, ik vind VB niks)?

[user109731]

.Gertjan. schreef op donderdag 26 maart 2009 @ 21:53:
Ik heb wel eens de tip gekregen om in plaats van

C#:

if ( x == 5) { }

gebruikt te maken van

C#:

if (5 == x) { }

Mocht je in een taal die het toewijzen in de if toestaat een = vergeten krijg je een error omdat je x niet aan de constante 5 mag toekennen.

Klopt. Er is wat voor te zeggen, maar ik vraag me af of er echt mensen zijn die dat consistent zo doen? Ik vind het nl. veel minder leesbaar. Misschien moet je eraan wennen maar tijdens het lezen ben ik langer bezig met 'verwerken' van (5 == x) dan (x == 5)

edit: overigens is zo'n bug in Python niet mogelijk omdat = een statement (ipv een expressie) is:

Python:

a = 1
b = (a == 1)
if a == 1: pass
if a = 1: pass # syntax error

edit 2: dat moet trouwens wel zo omdat dit anders ambigu zou zijn:

Python:

foo(a, b=3)

b is een named parameter, zou anders ook assignment kunnen zijn...

offtopic:
Het wordt tijd voor een Python highlighter, de grammatica is er eenvoudig genoeg voor

[ Voor 28% gewijzigd door user109731 op 26-03-2009 22:40 ]

[Verwijderd]

JanDM schreef op donderdag 26 maart 2009 @ 22:15:
[...]

Klopt. Er is wat voor te zeggen, maar ik vraag me af of er echt mensen zijn die dat consistent zo doen? Ik vind het nl. veel minder leesbaar. Misschien moet je eraan wennen maar tijdens het lezen ben ik langer bezig met 'verwerken' van (5 == x) dan (x == 5)

Ik heb het in 1 project zo gedaan, maar daarna heb ik 't nooit meer gedaan. Ik heb de fout namelijk nog nooit gemaakt, en het is inderdaad niet logisch, omdat je in natuurlijke taal je afvraagt of x gelijk is aan vijf, en niet of vijf gelijk is aan x.

[Woy]

.Gertjan. schreef op donderdag 26 maart 2009 @ 21:53:
[...]

Ik heb wel eens de tip gekregen om in plaats van

C#:

if ( x == 5) { }

gebruikt te maken van

C#:

if (5 == x) { }

Mocht je in een taal die het toewijzen in de if toestaat een = vergeten krijg je een error omdat je x niet aan de constante 5 mag toekennen.

In sommige talen is dat inderdaad het geval, maar in C# heb je er geen voordeel bij. Immers compilen beide volgende voorbeelden niet

C#:

if( x = 5 );
if( 5 = x );

Aangezien je in C# ( en ook java ) het statement in de if naar een bool moet evalueren. In C/C++ kan het inderdaad wel simpele typefouten voorkomen.

[Patriot]

l0c4lh0st schreef op donderdag 26 maart 2009 @ 21:50:
[...]

In dit geval wel, als je in plaats van 3 te assignen, 0 zou assignen, zou het false opleveren.

Je kijkt namelijk niet "of de toekenning lukt", maar wat de waarde is van $a. Dat is 3 en dat evalueert naar true.

Nu spreek je jezelf toch tegen? Je insinueert nu dat het toekennen van een 0 aan een variabele per definitie niet lukt? Hij geeft gewoon de waarde door.

[.Gertjan.]

Woy schreef op donderdag 26 maart 2009 @ 22:32:
[...]

In sommige talen is dat inderdaad het geval, maar in C# heb je er geen voordeel bij. Immers compilen beide volgende voorbeelden niet

C#:

if( x = 5 );
if( 5 = x );

Aangezien je in C# ( en ook java ) het statement in de if naar een bool moet evalueren. In C/C++ kan het inderdaad wel simpele typefouten voorkomen.

I know. Niet slim om het tussen C# code te zetten. Maar daarom zette ik het er ook onder dat het nuttig is om te gebruiken in talen die de toewijzing wel toestaan in de if. En C# kan dat inderdaad niet en zal je inderdaad een error geven als je if(x=5) { } gebruikt.

Sebazzz schreef op donderdag 26 maart 2009 @ 22:04:
@GertJan: Waarom zou je tussen VB en C# switchen, want het is een compleet andere syntax (die ik niet kan doorzien overigens, ik vind VB niks)?

Ik ben begonnen met C# (in .NET 1.1 en later 2.0).

Na een job change kwam ik in een bedrijf waar ze in VB.NET (2.0) werkte (omdat er programmeurs zaten die in oud ASP werkte en men het slim vond om ze om te scholen naar VB.NET, waar ik het niet mee eens ben ASP en VB.NET zijn totaal anders dus geef ze dan meteen een "goede" taal). Gelukkig had ik vroeger wat dingen in VB 5 gedaan waardoor ik de syntax van VB.NET snel doorhad.

Verder zijn de talen gelijkwaardig en delen ze het zelfde framework en je kan VB.NET bijna alles wat in C# ook kan (uitzondering is de inlineif, die werkt in VB compleet anders dan in C#). Vind het ook wel jammer dat in Visual Studio (zeker in 2003 en 2005) de ondersteuning voor VB.NET minder uitgebreid is dan voor C#. Zo kun je in VB minder refactoring toepassen dan in C#.

In dat bedrijf ben ik wel bezig geweest om ze over te laten stappen naar C#. De libraries werden in C# gemaakt (omdat de oude developers daar niet aan mee werkten) en de rest in VB.NET. Daardoor moest ik veel wisselen tussen de talen.

Het is alleen even wennen (zoals AND is niet gelijk aan &&. Daarvoor moet je ANDALSO gebruiken) en je moet niet meer achter ieder statement een ; zetten of blokken maken met { }. Gelukkig fluit de compiler je snel zat terug als je dat gaat doen.

In mijn nieuwe baan zit ik ook op een opdracht waar ze de voorkeur geven aan VB.NET zodat de webmaster mij kan helpen en zelf klein onderhoud kan doen. Maar in dat project heb ik weer een home-made (database) library binnengebracht die is geschreven in C# (die ik nog wat moest aanpassen).

De laatste jaren zit ik iets meer in VB dan in C#. Maar goed. Nu kan ik werken met C# en VB.NET en kan vrij snel wisselen. Dat zie ik maar als een voordeel. Mijn voorkeur gaat echter uit naar C# (voorbeelden en MSDN lees ik liever in C#) en heb ook mijn MCTS examens in C# gedaan. Was nooit een fan van VB.NET, maar heb er mee leren leven de laatste jaren

[Cartman!]

.oisyn schreef op donderdag 26 maart 2009 @ 21:21:
[...]

Ik vind dat maar een heel rare redenatie, dat als je het over de tekortkomingen hebt over de taal PHP en haar designteam dat je dan meteen PHP'ers als prutser afschildert . Blijkbaar ben je dus wél op je pik getrapt, anders trek je dat soort conclusies niet. Lijkt mij dan iig

Zo bedoel ik t niet helemaal. Er wordt zeker een hoop geprutst in PHP maar zeker niet door iedereen. Ik voel altijd een soort sfeer hier hangen dat PHP het slechtste is op de planneet en dat vind ik jammer. Ik schilder dus zelf PHPers als prutsers af maar het komt soms n beetje over alsof veel posters dat hier dus vinden, misschien is ie zo duidelijker

PHP is extreem tolerant en dat levert soms problemen op maar als je als gestructureerd werkt volgens een codestandaard hoeft dat helemaal niet nodig te zijn ondanks de tekortkomingen in de taal zelf.

[.oisyn]

Woy schreef op donderdag 26 maart 2009 @ 22:32:
[...]

In sommige talen is dat inderdaad het geval, maar in C# heb je er geen voordeel bij. Immers compilen beide volgende voorbeelden niet

C#:

if( x = 5 );
if( 5 = x );

Aangezien je in C# ( en ook java ) het statement in de if naar een bool moet evalueren. In C/C++ kan het inderdaad wel simpele typefouten voorkomen.

Tenzij de variabele zelf een boolean is. Nou zul je die niet vaak testen tegen een boolean literal, maar als je twee variabelen vergelijkt kan het dus alsnog misgaan. En dan heeft omdraaien ook niet veel nut

[Tiemez]

Michali schreef op donderdag 26 maart 2009 @ 21:13:
[...]

Snap ik, maar waarom, in vredesnaam, worden de waardes gecast naar een int als ik 2 strings vergelijk? Ik weet dat ik daarvoor eigenlijk strcmp moet gebruiken, maar ik vind het toch maar vreemd.

PHP:

var_dump( 0 == 'bier' );

ook zo'n leuke

[Grijze Vos]

.Gertjan. schreef op donderdag 26 maart 2009 @ 21:01:
[...]


De variabele zou in mijn ogen alleen binnen de if bestaan en daarna vervallen.

PHP heeft een variable scope op functie niveau, is nog niet in dit topic gezegd geloof ik.
Staat btw ook gewoon in de manual.

[ Voor 13% gewijzigd door Grijze Vos op 27-03-2009 03:26 ]

[YopY]

Cartman! schreef op donderdag 26 maart 2009 @ 23:00:
[...]

Zo bedoel ik t niet helemaal. Er wordt zeker een hoop geprutst in PHP maar zeker niet door iedereen. Ik voel altijd een soort sfeer hier hangen dat PHP het slechtste is op de planneet en dat vind ik jammer. Ik schilder dus zelf PHPers als prutsers af maar het komt soms n beetje over alsof veel posters dat hier dus vinden, misschien is ie zo duidelijker

Eensch, en ik denk dat de hoofdreden daarvan inderdaad is dat PHP toegangkelijk is. Hierdoor zijn er niet alleen veel mensen die willen beginnen met PHP, maar ook heeel veel websites die 'tutorials' aanbieden, en in de meeste gevallen geven die gewoon het verkeerde voorbeeld om maar zo eenvoudig mogelijk te blijven. Hetzelfde geldt voor boeken en dergelijke, die vaak ophouden nadat ze het stukje over databasetoegang gehad hebben - en vervolgens de belangrijke zaken zoals OO ( en de achterliggende gedachte ), veiligheid, goeie code, templates, enzovoort achterwege laten.

[Tanuki]

Patriot schreef op donderdag 26 maart 2009 @ 22:48:
[...]


Nu spreek je jezelf toch tegen? Je insinueert nu dat het toekennen van een 0 aan een variabele per definitie niet lukt? Hij geeft gewoon de waarde door.

Het toekennen van 0 aan een variabele lukt wel hoor.

Maar de if faalt, omdat 0 naar false evalueert.

Het gaat van:

PHP:

if ($a = 0)
{
    // doe iets
}

naar

PHP:

if (0)
{
    // doe iets
}

naar

PHP:

if (false)
{
    // doe iets
}

En dan wordt die if niet uitgevoerd.

[Patriot]

l0c4lh0st schreef op vrijdag 27 maart 2009 @ 09:23:
[...]

Het toekennen van 0 aan een variabele lukt wel hoor.

Ik zie dat ik je eerdere reactie verkeerd las. Je zei dat je juist níet keek of het toekennen gelukt was, ik dacht dat je zei dat het juist wél zo was (en het is inderdaad niet zo, wat ik ook in mijn reactie duidelijk probeerde te maken).

[Janoz]

Cartman! schreef op donderdag 26 maart 2009 @ 23:00:
[...]

Zo bedoel ik t niet helemaal. Er wordt zeker een hoop geprutst in PHP maar zeker niet door iedereen. Ik voel altijd een soort sfeer hier hangen dat PHP het slechtste is op de planneet en dat vind ik jammer. Ik schilder dus zelf PHPers als prutsers af maar het komt soms n beetje over alsof veel posters dat hier dus vinden, misschien is ie zo duidelijker

PHP is extreem tolerant en dat levert soms problemen op maar als je als gestructureerd werkt volgens een codestandaard hoeft dat helemaal niet nodig te zijn ondanks de tekortkomingen in de taal zelf.

Jij (en YopY) mis(t/sen) nog steeds het punt. De PHP bashing waar .oisyn het over heeft is niet vanwege de 'prutsers' die php applicaties maken, maar vanwege de prutsers die PHP zelf maken.

Neem nu de keuze voor namespace separator. Een backspacelash. Elke fatsoenlijke architect kan op zijn klompen aanvoelen dat dat voor problemen gaat zorgen met namespaces die bijvoorbeeld met een t, n of r beginnen.

[.oisyn]

Janoz schreef op vrijdag 27 maart 2009 @ 10:47:
De PHP bashing waar .oisyn het over heeft is niet vanwege de 'prutsers' die php applicaties maken, maar vanwege de prutsers die PHP zelf maken.

Exact. Er wordt gebashed op de taal zelf, niet op de gebruikers ervan.

[netvor]

.oisyn schreef op donderdag 26 maart 2009 @ 21:38:
PHP kent gewoon geen block scoping. Daar is an sich niet zo heel veel mis mee, en er zijn wel meer talen die dat niet doen (bijv. C en Javascript).

Loop initialization scope is inderdaad een lastig puntje als je met C aan het werk bent, aangezien het van de gebruikte taalstandaard (en dus van je compiler) afhangt wat er gebeurt: in "oude C" vielen de statements in de initializer buiten de scope van de loop, in "nieuwe C" erbinnen á la C++.

Bij een vorige baan werd embedded SW geschreven, en werd er gebruik gemaakt van een stukje preprocessing om dit:

C:

for (int i=0; i<max; i++)
{
  do(i);
}

automagisch om te zetten in dit:

C:

{
  for (int i=0; i<max; i++)
  {
    do(i);
  }
}

Want anno 2007 is het natuurlijk helemaal hip en retro om een C89 compiler te gebruiken.

EDIT:
Wat betreft het PHP debat: IMHO is de kern van het probleem dat PHP al lang geleden zijn basis ontgroeid is: het was bedoeld als een makkelijk taaltje om iets als server-side includes mee te doen, zoals een hitcountertje of iets anders ouderwets, en niet voor volledige webapplicaties (die overigens in die jaren niet echt bestonden in hun huidige vorm). Vervolgens zijn er tijd lang features aan toegevoegd, min of meer zonder planning of structuur, en tot slot zijn er nog wat OOP features tegenaan getimmerd. Het is de shanty town van programmeertalen.

[ Voor 23% gewijzigd door netvor op 27-03-2009 11:08 ]

[Tanuki]

Janoz schreef op vrijdag 27 maart 2009 @ 10:47:
[...]

Neem nu de keuze voor namespace separator. Een backspace. Elke fatsoenlijke architect kan op zijn klompen aanvoelen dat dat voor problemen gaat zorgen met namespaces die bijvoorbeeld met een t, n of r beginnen.

Je bedoelt een backslash en dat vind ik ook een vreemde keuze. Maar wellicht was het het enige mogelijke karakter.

Ik zie alleen niet echt in waarom namespaces met een t, n of r beginnen een probleem zouden zijn? Control characters zijn toch helemaal niet van toepassing op namespaces?

[.oisyn]

Een conforming C89/90 compiler zal het sowieso niet compilen, dan moeten alle definities boven alle overige statements staan in een functie

l0c4lh0st schreef op vrijdag 27 maart 2009 @ 11:00:
Ik zie alleen niet echt in waarom namespaces met een t, n of r beginnen een probleem zouden zijn? Control characters zijn toch helemaal niet van toepassing op namespaces?

Wel in function "references", die in PHP helaas nog met strings werken

[ Voor 56% gewijzigd door .oisyn op 27-03-2009 11:02 ]

[MBV]

.Gertjan. schreef op donderdag 26 maart 2009 @ 21:15:
Vind ik heel eng. Dit is leuk voor hele getallen. Als je met decimalen gaat werken gaat dit mis. Want wanneer is het een punt en wanneer een komma. Als je dan waardes bij elkaar op gaat tellen zou het soms mis gaan.

Dat is nog zo'n leuke feature van PHP: dat hangt af van de locale-settings

Oh ja, probeer eens in VBScript een programma te schrijven dat, onafhankelijk van de taalinstellingen, altijd data uitspuugt in het goede formaat, en in het goede formaat inleest

[jbdeiman]

Janoz schreef op vrijdag 27 maart 2009 @ 10:47:
[...]


Jij (en YopY) mis(t/sen) nog steeds het punt. De PHP bashing waar .oisyn het over heeft is niet vanwege de 'prutsers' die php applicaties maken, maar vanwege de prutsers die PHP zelf maken.

Neem nu de keuze voor namespace separator. Een backspace (Laat ik toch hopen dat je een backslash bedoeld, anders haal je een character weg). Elke fatsoenlijke architect kan op zijn klompen aanvoelen dat dat voor problemen gaat zorgen met namespaces die bijvoorbeeld met een t, n of r beginnen.

PHP is juist door die "prutsers" die het maken (de PHP source zelf) zo laagdrempelig gebleven. Zonder dat was het internet waarschijnlijk niet zo groot en toegankelijk geweest als het nu is. Er zit wel degelijk een gedachte achter en die gedachte was altijd om het zo laagdrempelig mogelijk te houden.

Daarnaast wordt PHP zoveel gebruikt ook door professionele ontwikkelaars dat ze de laatste jaren bezig zijn geweest met het professionaliseren van de mogelijkheden van PHP. (Bijv. De OOP syntax en dergelijke)

Het bashen van de PHP bouwers is, in mijn ogen, dan ook onterecht. Natuurlijk is PHP veel te vrij (dat vind ik, tevens een PHP programmeur, ook) waardoor je code niet altijd goed is en waardoor je vaak fouten krijgt, zeker bij beginners.
Wanneer je echter gestructureerd werkt, en zeker tijdens de ontwikkeling alle fouten/ waarschuwingen weergeeft, dan zal je vanzelf ook netter en beter programmeren. (denk bijv. aan het definiëren van variabelen, het foutafhandelen bij Query's enz.) Ik zeg niet dat wat ik schrijf foutloos is, maar ik durf wel te zeggen dat je niet zomaar echte fouten tegenkomt.
Ik vind het wel prettig dat PHP ook steeds meer de kant op gaat van een OOP programmeertaal, maar dat de "procedurele syntax" nog wel beschikbaar is. Zeker als je "even snel iets moet maken" kan dat veel sneller procedureel dan echt in OOP. Meestal maak ik dan een simpele functie die aangeroepen kan worden. Net zo snel en effectief, alleen niet via een class aanroepbaar, maar daar is die ook snel genoeg in te bouwen indien nodig.

[Janoz]

.oisyn schreef op donderdag 26 maart 2009 @ 21:46:
Duh, C#, C, C++ en Java ook. Wat is je punt? C-like talen gebruiken een = voor de assignment en de == voor vergelijking. Pascal gebruikt een := voor assignment en = voor vergelijking (en kent dus niet maar "1 soort ="). In VB heb je wel alleen maar een = voor zowel de assignment als de vergelijking.

Eigenlijk is de Pascal manier wiskundig gezien de meest correcte.

= staat voor 'is gelijk aan'

:= staat voor 'wordt'.

Zie ook http://en.wikipedia.org/wiki/Table_of_mathematical_symbols.

[Zoijar]

Janoz schreef op vrijdag 27 maart 2009 @ 11:05:
:= staat voor 'wordt'.

Ik dacht altijd dat := betekent "is per definitie", dus dat zou je mijnsinziens alleen voor constanten kunnen gebruiken dan.

voor een assignment is volgens mij de pijl naar links standaard in de wiskunde, i.e. x <-- 42

[ Voor 15% gewijzigd door Zoijar op 27-03-2009 11:13 ]

[.oisyn]

jbdeiman schreef op vrijdag 27 maart 2009 @ 11:03:
[...]


PHP is juist door die "prutsers" die het maken (de PHP source zelf) zo laagdrempelig gebleven. Zonder dat was het internet waarschijnlijk niet zo groot en toegankelijk geweest als het nu is. Er zit wel degelijk een gedachte achter en die gedachte was altijd om het zo laagdrempelig mogelijk te houden.

Sorry hoor maar dit vind ik echt complete onzin. Laagdrempeligheid is niet hetzelfde als het simpelweg niet nadenken over features, maar gewoon maar wat doen en zien waar het schip strandt. Je kunt echt een hele rits wijzigingen aan de taal maken zodat het wél enigszins fatsoenlijk werkt, zonder dat je die laagdrempeligheid daarmee overhoop haalt.

Natuurlijk is PHP veel te vrij (dat vind ik, tevens een PHP programmeur, ook) waardoor je code niet altijd goed is en waardoor je vaak fouten krijgt, zeker bij beginners.

Het gaat er helemaal niet om dat het te vrij is. Het gaat erom dat er niet over dingen wordt nagedacht. Dingen waar beginners ook continu tegenaan lopen. Als je zegt dat 0 gelijk is aan "aap" ben je gewoon idioot bezig. En nee, dat volgt niet uit het feit dat je wilt dat 0 wel gelijk moet zijn aan "0". Als een string niet converteerbaar is naar een int, is hij dus ook niet 0! Dit is tevens ook helemaal geen designkeuze geweest van PHP. Het is simpelweg een gevolg van de implementatie, die toevallig zo uitpakte. En zo gaat het met heel veel features in PHP.

Zoijar schreef op vrijdag 27 maart 2009 @ 11:12:
voor een assignment is volgens mij de pijl naar links standaard in de wiskunde, i.e. x <-- 42

Nee daar staat x kleiner dan 41 (als je een r-value mocht decrementen dan)

[ Voor 17% gewijzigd door .oisyn op 27-03-2009 11:20 ]

[Zoijar]

Ach, PHP was ooit nuttig voor wat het deed. Nu is het uit de hand gelopen, de taal is te ver gegroeid en uitgerekt. Eigenlijk is het idioot dat ze niet een complete revisie doen. Maar ik snap ook wel waarom ze dat niet doen... Als je het namelijk echt goed wilt maken, dan kom je al snel op een C# clone uit, en wat is dan nog het bestaansrecht van PHP? Plus dat het waarschijnlijk te moeilijk is en te veel tijd kost, en alle compatibiliteit met voorgaande versies breekt. Soms moet dat nou eenmaal, dat zie je toevallig aan OpenGL nu. Die hebben gelukkig op tijd ingezien dat als ze zo door gaan, dat het einde in zicht is

.oisyn schreef op vrijdag 27 maart 2009 @ 11:15:
Nee daar staat x kleiner dan 41 (als je een r-value mocht decrementen dan)

Haha, ja ja Moet jij niet wat bugs uit tombraider vissen ofzo?

[ Voor 24% gewijzigd door Zoijar op 27-03-2009 11:22 ]

[XWB]

Laat hem liever wat opschieten met Deus Ex 3

[Janoz]

jbdeiman schreef op vrijdag 27 maart 2009 @ 11:03:
[...]


PHP is juist door die "prutsers" die het maken (de PHP source zelf) zo laagdrempelig gebleven. Zonder dat was het internet waarschijnlijk niet zo groot en toegankelijk geweest als het nu is. Er zit wel degelijk een gedachte achter en die gedachte was altijd om het zo laagdrempelig mogelijk te houden.

Nu ken je wel ontiegelijk veel eer aan php toe. Het internet was al heel groot en toegankelijk voor PHP, en als je al iets zou moeten kiezen dan zou ik eerder voor MySQL kiezen. Een werkbare gratis database.

'De enige echte werkwijze die php toepast is de voglende :

Stap 1:
We bedenken een coole nieuwe feature of taal uitbreiding omdat dat veel gevraagd wordt, of gewoon hip klinkt. Deze implementeren we zonder een uitgebreide analyse.

Stap 2:
Proberen met kunst en vliegwerk de in stap 1 geïntroduceerde quirks backwardscompatible te houden wanneer blijkt dat bepaalde keuzes toch meer impact bleken te hebben.

Parallel hieraan:
Proberen in de bugreports het onlogisch zijn van bepaalde onderdelen te verdedigen door de technische implementatie uit te leggen, en daarbij volledig het werkelijke probleem te negeren.

Daarnaast wordt PHP zoveel gebruikt ook door professionele ontwikkelaars dat ze de laatste jaren bezig zijn geweest met het professionaliseren van de mogelijkheden van PHP. (Bijv. De OOP syntax en dergelijke)

De OOP syntax is alvast een typisch voorbeeld van een grote WTF. Keurig te mappen op de stappen hierboven. Als ze ook maar ietsje pietsje langer hadden nagedacht en eens wat research hadden gedaan naar het concept van OOP dan hadden ze gelijk in de eerste versie al geïmplementeerd dat de constructor van een class automatisch als eerste ook de constructor van zijn superclass aan zou roepen.

Het bashen van de PHP bouwers is, in mijn ogen, dan ook onterecht. Natuurlijk is PHP veel te vrij (dat vind ik, tevens een PHP programmeur, ook) waardoor je code niet altijd goed is en waardoor je vaak fouten krijgt, zeker bij beginners.

Vrijheid is niet het probleem.Je kunt keurig een logisch goed in elkaar steken compleet vrije taal ontwikkelen. Sommige taalkeuzes zijn echter gewoon onlogisch. Neem enkel bovenstaand voorbeeld waarbij 2 strings worden vergeleken. Als beide zijnden van de == al van hetzelfde type zijn, waarom in godensnaam gaan ze deze dan alsnog naar een int casten ...

Wanneer je echter gestructureerd werkt, en zeker tijdens de ontwikkeling alle fouten/ waarschuwingen weergeeft, dan zal je vanzelf ook netter en beter programmeren. (denk bijv. aan het definiëren van variabelen, het foutafhandelen bij Query's enz.) Ik zeg niet dat wat ik schrijf foutloos is, maar ik durf wel te zeggen dat je niet zomaar echte fouten tegenkomt.

Het gaat niet over hoe gestructureerd jij werkt en hoeveel fouten jij niet maakt. Het gaat over de competenties van de mensen achter PHP. Hierboven zijn al meerdere voorbeelden die aangeven dat ze incapabel zijn om de impact van bepaalde ontwerpbeslissingen te kunnen onderkennen.

Ik vind het wel prettig dat PHP ook steeds meer de kant op gaat van een OOP programmeertaal, maar dat de "procedurele syntax" nog wel beschikbaar is. Zeker als je "even snel iets moet maken" kan dat veel sneller procedureel dan echt in OOP. Meestal maak ik dan een simpele functie die aangeroepen kan worden. Net zo snel en effectief, alleen niet via een class aanroepbaar, maar daar is die ook snel genoeg in te bouwen indien nodig.

PHP gaat helemaal niet de kant op van OOP. Ze hebben een tijd terug de verkeerde afslag genomen en zijn langzamerhand aan het verdwalen op binnenweggetjes op zoek naar de weg naar OOP.

[user109731]

Zoijar schreef op vrijdag 27 maart 2009 @ 11:20:
Ach, PHP was ooit nuttig voor wat het deed. Nu is het uit de hand gelopen, de taal is te ver gegroeid en uitgerekt. Eigenlijk is het idioot dat ze niet een complete revisie doen. Maar ik snap ook wel waarom ze dat niet doen... Als je het namelijk echt goed wilt maken, dan kom je al snel op een C# clone uit, en wat is dan nog het bestaansrecht van PHP?

Mwa, ik denk dat een "goede PHP" dichterbij Python of Ruby zit.

C# is als taal wel mooi, maar ASP.NET zuigt imho. Ik heb ooit eens onderhoud moeten doen aan zo'n website en daar kwam de meest bagger HTML uit. Uiteindelijk met wat CSS-hacks 'opgelost'... Ik wil gewoon de volledige controle over m'n HTML/CSS/JS hebben

Ik denk dat er best wel bestaansrecht is voor een nieuwe (of bestaande) scripttaal gericht op het web. Een goed framework met classes/namespaces voor MySQL, regex'en, cookies, etc. Er was hier laatst een topic over een nieuwe scripttaal, helaas lijkt dat doodgebloed

Iemand trouwens ervaring met server-side Javascript frameworks? Er zijn nu snelle JS-interpreters, en het voordeel is dat je met 1 taal bezig bent en code kunt delen tussen server-side en client-side..

[.oisyn]

Janoz schreef op vrijdag 27 maart 2009 @ 11:55:
Neem enkel bovenstaand voorbeeld waarbij 2 strings worden vergeleken. Als beide zijnden van de == al van hetzelfde type zijn, waarom in godensnaam gaan ze deze dan alsnog naar een int casten ...

Niet om PHP te verdedigen, maar volgens mij klopt dat voorbeeld niet. Als beide zeiden idd van het type string zijn, dan wordt de string gewoon vergeleken. "aap" == "0" levert gewoon false op zoals je zou verwachten.

JanDM schreef op vrijdag 27 maart 2009 @ 11:56:
Ik denk dat er best wel bestaansrecht is voor een nieuwe (of bestaande) scripttaal gericht op het web. Een goed framework met classes/namespaces voor MySQL, regex'en, cookies, etc. Er was hier laatst een topic over een nieuwe scripttaal, helaas lijkt dat doodgebloed

Proton language proposal

[ Voor 30% gewijzigd door .oisyn op 27-03-2009 12:05 ]

[Janoz]

Zoijar schreef op vrijdag 27 maart 2009 @ 11:12:
[...]

Ik dacht altijd dat := betekent "is per definitie", dus dat zou je mijnsinziens alleen voor constanten kunnen gebruiken dan.

voor een assignment is volgens mij de pijl naar links standaard in de wiskunde, i.e. x <-- 42

Helemaal 'wordt' is het niet. Eventueel zou je het kunnen lezen als 'gedefinieerd als'. Het is (heel kort door de bocht) wel zo dat het teken aangeeft dat de linker gelijk gesteld wordt aan de rechter.

De correctheid van de pascal keuze is imho meer dat ze = niet voor een toewijzing gebruiken, maar echt als een vergelijking.

Als je een wiskundige zou vragen wat het volgende stukje code zou doen:

code:

a = 3
b = 4
a = b

Dan zou hij zeggen 'onwaar'.

[jbdeiman]

.oisyn schreef op vrijdag 27 maart 2009 @ 11:15:
[...]
Sorry hoor maar dit vind ik echt complete onzin. Laagdrempeligheid is niet hetzelfde als het simpelweg niet nadenken over features, maar gewoon maar wat doen en zien waar het schip strandt. Je kunt echt een hele rits wijzigingen aan de taal maken zodat het wél enigszins fatsoenlijk werkt, zonder dat je die laagdrempeligheid daarmee overhoop haalt.
[...]
Het gaat er helemaal niet om dat het te vrij is. Het gaat erom dat er niet over dingen wordt nagedacht. Dingen waar beginners ook continu tegenaan lopen. Als je zegt dat 0 gelijk is aan "aap" ben je gewoon idioot bezig. En nee, dat volgt niet uit het feit dat je wilt dat 0 wel gelijk moet zijn aan "0". Als een string niet converteerbaar is naar een int, is hij dus ook niet 0! Dit is tevens ook helemaal geen designkeuze geweest van PHP. Het is simpelweg een gevolg van de implementatie, die toevallig zo uitpakte. En zo gaat het met heel veel features in PHP.

PHP werkt wel fatsoenlijk, alleen veel van de features die je in andere programmeertalen hebt zijn weggelaten. PHP is eigenlijk maar een heel kleine taal en eigenlijk niet eens een echte programmeertaal, maar meer een scripttaal.

Ik vind het juist wel handig die implementatie van == en === en gebruik dat ook best wel regelmatig, zowel de == als de ===
0 is niet gelijk aan "0" in de zin van dat het type variabele niet overeenkomt, zet je echter het 1 om in het ander (waarbij het niet uitmaakt of je de int typecast naar een string of andersom) dan is het wel hetzelfde. Wat dan weer wel logischer zou zijn geweest is == gebruiken om echt te vergelijken, dus type/ waarde en === voor de losse vergelijking. Je leert dan vanzelf netter/ beter scripten met de taal, omdat iedereen normaal gesproken == gebruikt.
De vrije implementatie van variabele typen is overigens wel een keuze geweest. Juist dat soort dingen (het niet zo strak houden aan al die regeltjes, 100 manieren om hetzelfde te bereiken (bij wijze van)) maakt het een laagdrempelige taal. Echter is dat een keuze geweest die voor de die hard programmeurs onder ons niet goed te begrijpen is. Het heeft er wel mede voor gezorgd dat het internet is wat het nu is, met ASP.NET hadden we nooit zoveel websites gehad als dat die er nu zijn.

[Janoz]

JanDM schreef op vrijdag 27 maart 2009 @ 11:56:
[...]

Mwa, ik denk dat een "goede PHP" dichterbij Python of Ruby zit.

C# is als taal wel mooi, maar ASP.NET zuigt imho. Ik heb ooit eens onderhoud moeten doen aan zo'n website en daar kwam de meest bagger HTML uit. Uiteindelijk met wat CSS-hacks 'opgelost'... Ik wil gewoon de volledige controle over m'n HTML/CSS/JS hebben

Ik niet. Ik wil graag productief bezig zijn, en niet uren bezig zijn met allerlei tweaks en hacks om de css en js in alle browsers werkend te krijgen. Dat besteed ik liever uit aan een fatsoenlijke library die als primair doel heeft om alles overal goed en netjes werkend te krijgen. Denk daarbij bijvoorbeeld aan jQuery, maar ook aan GWT.

(Dat MS er vervolgens niet in slaagt om het laatste te doen is meer een issue van hun widget implementatie dan van het concept _{--edit-- .GertJan. legt dat een paar post hieronder uitstekend uit})

Ikzelf ben ook niet altijd blij met de code die mijn JSF applicatie oplevert, maar het is werkbaarder dan alles altijd maar helemaal zelf te doen (gelukkig heb je bij JSF meer keuzes in widget implementaties en leveren deze imho ook betere html op)

Iemand trouwens ervaring met server-side Javascript frameworks? Er zijn nu snelle JS-interpreters, en het voordeel is dat je met 1 taal bezig bent en code kunt delen tussen server-side en client-side..

Ik ken alleen een voorbeeld andersom. Met het bovengenoemde GWT kun je javacode compileren naar javascript code. Dan kun je op de server en op de client met dezelfde codebase blijven werken.

[.oisyn]

jbdeiman schreef op vrijdag 27 maart 2009 @ 12:01:
[...]


PHP werkt wel fatsoenlijk, alleen veel van de features die je in andere programmeertalen hebt zijn weggelaten. PHP is eigenlijk maar een heel kleine taal en eigenlijk niet eens een echte programmeertaal, maar meer een scripttaal.

Jij denkt blijkbaar net zo hard na over je antwoorden als dat Zend nadenkt over hun features

Ik vind het juist wel handig die implementatie van == en === en gebruik dat ook best wel regelmatig, zowel de == als de ===
0 is niet gelijk aan "0" in de zin van dat het type variabele niet overeenkomt, zet je echter het 1 om in het ander (waarbij het niet uitmaakt of je de int typecast naar een string of andersom) dan is het wel hetzelfde

En dat is idd een mooie feature. Dat zijn ze gaan implementeren. En toen bleek ineens dat een string als "aap" óók gelijk is aan 0. En dát slaat nergens op. Javascript en Python doen dit ook gewoon goed, het is dus niet dat het niet kan. In pseudocode:

code:

bool compare(var a, var b)
{
    if (a.isString() && b.isString())
        return a.getString() == b.getString();
    if (a.isInt() && b.isInt())
        return a.getInt() == b.getInt();

    if (a.isInt()) // dus b is string
        return b.canConvertToInt() && a.getInt() == b.convertToInt();
    else // dus a is string en b is int
        return a.canConvertToInt() && b.getInt() == a.convertToInt();
}

PHP slaat nu die hele canConvertToInt() stap over. Ze converteren gewoon, en voor een niet-int resulteert dat in 0. Maar een niet-int is geen 0! Mijn hele punt is: je kunt het goed laten werken, zonder dat je daarmee de 'feature' dat je een int kunt vergelijken met een string overboord gooit. Maar dat wil er bij jou blijkbaar niet in. Het is geen keuze geweest van het PHP team om een willekeurige string gelijk te laten zijn aan 0. Het is iets dat toevallig voortkwam uit de manier waarop het geïmplementeerd wordt. Op het moment dat je dat vervolgens bij hen als 'bug' aandraagt, verdedigen ze zich door te zeggen dat het geen bug is omdat de implemtatie zo werkt. Ja, duh, op die manier is *niets* een bug - de implementatie is immers zo.

Het non-argument "gebruik ===" wordt idd vaak gebezigd door PHP programmeurs, maar het slaat nergens op (ter verdediging van de manier waarop het momenteel werkt bedoel ik). Wat nou als je een int met een float wilt vergelijken? Dan kun je de === dus al niet meer gebruiken. Je hele argument is gebaseerd op het feit dat je het wel moet gebruiken omdat de feature nou eenmaal zo krom in elkaar zit. Je redeneert dus verkeerd om. Het is een workaround die nodig is door een rare implementatie. Het is niet dat de implementatie zo is omdat je === moet gebruiken als je wat anders wilt!

Maar even compleet los van hoe het geïmplementeerd wordt en hoe PHP momenteel werkt, welke van de volgende twee situaties vind jij duidelijker, intuitiever en/of makkelijker om mee te werken:

A

==	0	1	"0"	"1"	"aap"
0	true	false	true	false	true
1	false	true	false	true	false
"0"	true	false	true	false	false
"1"	false	true	false	true	false
"aap"	true	false	false	false	true

B

==	0	1	"0"	"1"	"aap"
0	true	false	true	false	false
1	false	true	false	true	false
"0"	true	false	true	false	false
"1"	false	true	false	true	false
"aap"	false	false	false	false	true

[ Voor 171% gewijzigd door .oisyn op 27-03-2009 12:46 ]

[Zoijar]

jbdeiman schreef op vrijdag 27 maart 2009 @ 12:01:
De vrije implementatie van variabele typen is overigens wel een keuze geweest.

Volgens mij is dat alleen een keuze geweest omdat het makkelijker te implementeren is. Dat idee krijg ik wel vaker bij PHP. Waarom gebruiken ze een \ voor namespaces? Omdat ze dan met een simpele LR parser meteen kunnen zien wat er bedoeld wordt, wat een noodzakelijk gevolg is van het feit dat ze te weinig informatie over identifiers opslaan. Het begon denk ik met het simpelweg opslaan van variabelen in een hash tabel met interne values van type "void*", zodat ze alles met dezelfde code konden opslaan en verwerken. Die simpele aanpak was prima voor een webscripting taal in de tijd dat je alleen wat simpele output genereerde, maar is echt te simplistisch voor een full-featured taal die het nu claimed te zijn waar volledige applicaties in ontwikkeld worden. Dat is de hele moeilijkheid met PHP, dat de kern, de grondslag, niet goed in elkaar zit. Vervolgens zullen alle nieuwe features problemen ondervinden omdat de kern rot is.

[.Gertjan.]

JanDM schreef op vrijdag 27 maart 2009 @ 11:56:
[...]

Mwa, ik denk dat een "goede PHP" dichterbij Python of Ruby zit.

C# is als taal wel mooi, maar ASP.NET zuigt imho. Ik heb ooit eens onderhoud moeten doen aan zo'n website en daar kwam de meest bagger HTML uit. Uiteindelijk met wat CSS-hacks 'opgelost'... Ik wil gewoon de volledige controle over m'n HTML/CSS/JS hebben

Ik denk dat er best wel bestaansrecht is voor een nieuwe (of bestaande) scripttaal gericht op het web. Een goed framework met classes/namespaces voor MySQL, regex'en, cookies, etc. Er was hier laatst een topic over een nieuwe scripttaal, helaas lijkt dat doodgebloed

Iemand trouwens ervaring met server-side Javascript frameworks? Er zijn nu snelle JS-interpreters, en het voordeel is dat je met 1 taal bezig bent en code kunt delen tussen server-side en client-side..

Of ASP.NET rommel HTML eruit gooit hangt er een beetje van af wat je ermee gaat doen. Je kunt ieder control voorzien van een object wat verantwoordelijk is voor het renderen (ik geloof dat dat adapters waren). Dus volledige controle over je html heb je wel. Ik schrijf ook vaak genoeg controls en pages die geen gebruik maken van de standaard controls, maar gewoon html elementen en waarbij ik zelf in de postdata duik. Dat het erin zit betekend niet dat je het moet gebruiken. Vooral rechten en validaties zijn binnen het framework mooi geregeld.

Ik heb liever honderden componenten waarvan ik er een aantal niet gebruik omdat ze rommel genereren dan een kale taal als PHP waar je zelf verantwoordelijk bent voor je "controls". Als je textboxes gebruikt in .NET hoef je niets te doen met je postdata (dit wordt door het framework zelf afgehandeld), in PHP moet je zelf maar gaan rommelen in je postdata of zelf op iedere pagina checken of iemand rechten heeft.

En daarbij: ASP.NET is een subset van het .NET framework en is sinds 1.1 iedere keer beter geworden. Ik vind dat er sinds 2.0 makkelijk mee gewerkt kan worden.

[HawVer]

Janoz schreef op vrijdag 27 maart 2009 @ 12:05:
[...]

Ik niet. Ik wil graag productief bezig zijn, en niet uren bezig zijn met allerlei tweaks en hacks om de css en js in alle browsers werkend te krijgen. Dat besteed ik liever uit aan een fatsoenlijke library die als primair doel heeft om alles overal goed en netjes werkend te krijgen. Denk daarbij bijvoorbeeld aan jQuery, maar ook aan GWT.

Maar zodra je wat verder wil gaan dan een sleep en pleur, data applicatie moet je zelf allerlei bochten gaan wringen om er wat fatsoenlijks uit te krijgen.

[Janoz]

Dat herken ik absoluut niet. Ten eerste heb ik nog nooit sleep en pleur hoeven toepassen. Ten tweede heb ik absoluut niet het gevoel dat ik me in allerlei bochten moet wringen om wat fatsoenlijks te krijgen.

Ik heb snel even iets gepakt uit het project waar ik nu aan werk:

Java Server Faces:

<fieldset id="correspondentieadresKeuze">
    <legend>
        <h:outputText value="#{messageSource.l_correspondentieadres_hetzelfde_als_woonadres}" escape="false" />
    </legend>
    <h:selectOneRadio 
            id="corradresvraag" 
            layout="pageDirection" 
            value="#{state.vraagCorrespondentieadres}"
            required="true" 
            requiredMessage="#{messageSource.f_verplichte_vraag_niet_beantwoord}"
            class="radio">
        <f:selectItem itemValue="NEE" itemLabel="#{messageSource.l_nee}" />
        <f:selectItem itemValue="JA" itemLabel="#{messageSource.l_ja}" />
        <a4j:support event="onclick" reRender="correspondentieadres" ajaxSingle="true"/>                    
    </h:selectOneRadio>
    <h:message for="corradresvraag" styleClass="foutmelding" />
</fieldset>

Dit renderd een keurige radiobutton vraag in nette html, gebruik makend van de label tag. Daarnaast wordt er automatisch ook een stuk javascript code voor mij gegenereerd die automatisch het volgende formulierveld zichtbaar maakt waarin een correspondentie adres ingevuld kan worden.

De uiteindelijke HTML is (ongeveer, ik heb zelf enkel whitespace aangepast)

HTML:

<fieldset id="correspondentieadresKeuze">
<legend>Wil je post op een ander adres ontvangen?</legend>
<table id="mainform:corradresvraag" class="radio">
<tbody><tr><td>
  <input name="mainform:corradresvraag" id="mainform:corradresvraag:0" value="NEE" onclick="A4J.AJAX.Submit('_viewRoot','mainform',event,{'parameters':{'mainform:j_id57':'mainform:j_id57','ajaxSingle':'mainform:corradresvraag'} ,'actionUrl':'/abf-sf-web/pages/instroom/adres.xhtml','similarityGroupingId':'mainform:j_id57','control':this} )" type="radio">
  <label for="mainform:corradresvraag:0"> nee</label>
</td>
</tr>
<tr>
<td>
  <input name="mainform:corradresvraag" id="mainform:corradresvraag:1" value="JA" onclick="A4J.AJAX.Submit('_viewRoot','mainform',event,{'parameters':{'mainform:j_id57':'mainform:j_id57','ajaxSingle':'mainform:corradresvraag'} ,'actionUrl':'/abf-sf-web/pages/instroom/adres.xhtml','similarityGroupingId':'mainform:j_id57','control':this} )" type="radio">
  <label for="mainform:corradresvraag:1"> ja</label>
</td>
</tr>
</tbody></table>
</fieldset>

Enkel de javascript in het event lijkt wat vreemd, en helemaal gelukkig met de keuze voor een tabel ben ik niet, maar voor de rest is het keurige en goed stijlbare html.

Uiteindelijk is het zelfs zo dat we voor de webrichtlijnen van de overheid ongeveer een score van 95% halen.op dit moment.

[Grijze Vos]

JanDM schreef op vrijdag 27 maart 2009 @ 11:56:
[...]

Mwa, ik denk dat een "goede PHP" dichterbij Python of Ruby zit.

C# is als taal wel mooi, maar ASP.NET zuigt imho. Ik heb ooit eens onderhoud moeten doen aan zo'n website en daar kwam de meest bagger HTML uit. Uiteindelijk met wat CSS-hacks 'opgelost'... Ik wil gewoon de volledige controle over m'n HTML/CSS/JS hebben

No offense, maar wat een complete bullshit. Misschien moet de originele schrijver van die site dan eens leren programmeren? Kan je zo wijzen naar enkele sites die wij hier ontwikkeld hebben die echt prima (X)HTML uitspugen. Als je interesse hebt kan ik je wel wat linkjes DMmen, of hier neerzetten, als dat mag van een modje.

[Snake]

Janoz schreef op vrijdag 27 maart 2009 @ 11:55:


[...]

De OOP syntax is alvast een typisch voorbeeld van een grote WTF. Keurig te mappen op de stappen hierboven. Als ze ook maar ietsje pietsje langer hadden nagedacht en eens wat research hadden gedaan naar het concept van OOP dan hadden ze gelijk in de eerste versie al geïmplementeerd dat de constructor van een class automatisch als eerste ook de constructor van zijn superclass aan zou roepen.


[...]

Hoe kun je dan kiezen welke constructor van de superklas je aanroept? En wat als je multiple inheritance hebt? Lijkt me toch iets waar wel goed over is nagedacht

[HawVer]

Grijze Vos schreef op vrijdag 27 maart 2009 @ 14:20:
[...]
Kan je zo wijzen naar enkele sites die wij hier ontwikkeld hebben die echt prima (X)HTML uitspugen. Als je interesse hebt kan ik je wel wat linkjes DMmen, of hier neerzetten, als dat mag van een modje.

Laat maar komen.. Ik ben wel benieuwd.

[mithras]

Snake schreef op vrijdag 27 maart 2009 @ 15:01:
[...]

Hoe kun je dan kiezen welke constructor van de superklas je aanroept? En wat als je multiple inheritance hebt? Lijkt me toch iets waar wel goed over is nagedacht

Volgens mij bedoelt hij iets als dit:

PHP:

class Animal{
  protected $sound;
  public function __construct( $sound ){
    $this->sound = $sound;
  }
  public function makeSound(){
    return $this->sound;
  }
}
class Dog extends Animal{}
class Labrador extends Dog{}

$myPet = new Labrador( 'bark' );
echo $myPet->makeSound(); //bark

Volgens mij was dat iets wat eerst niet werkte. Nu wel

[.oisyn]

Snake schreef op vrijdag 27 maart 2009 @ 15:01:
[...]

Hoe kun je dan kiezen welke constructor van de superklas je aanroept? En wat als je multiple inheritance hebt? Lijkt me toch iets waar wel goed over is nagedacht

Dat kun je in talen als C++ en Java toch ook? Het punt is, je kunt het in die talen niet vergeten. In PHP gebeurt er gewoon niets als je geen superclass ctor aanroept. In andere talen wordt in dat geval de default ctor aangeroepen (als die bestaat, anders error). En met de destructor heb je het door jouw aangehaalde probleem niet eens, maar ook daar moet je zelf nog even een call toevoegen.

En PHP kent geen multiple class inheritance.

[ Voor 12% gewijzigd door .oisyn op 27-03-2009 16:02 ]

[Cartman!]

Janoz schreef op vrijdag 27 maart 2009 @ 14:04:
De uiteindelijke HTML is (ongeveer, ik heb zelf enkel whitespace aangepast)

HTML:

<fieldset id="correspondentieadresKeuze">
<legend>Wil je post op een ander adres ontvangen?</legend>
<table id="mainform:corradresvraag" class="radio">
<tbody><tr><td>
  <input name="mainform:corradresvraag" id="mainform:corradresvraag:0" value="NEE" onclick="A4J.AJAX.Submit('_viewRoot','mainform',event,{'parameters':{'mainform:j_id57':'mainform:j_id57','ajaxSingle':'mainform:corradresvraag'} ,'actionUrl':'/abf-sf-web/pages/instroom/adres.xhtml','similarityGroupingId':'mainform:j_id57','control':this} )" type="radio">
  <label for="mainform:corradresvraag:0"> nee</label>
</td>
</tr>
<tr>
<td>
  <input name="mainform:corradresvraag" id="mainform:corradresvraag:1" value="JA" onclick="A4J.AJAX.Submit('_viewRoot','mainform',event,{'parameters':{'mainform:j_id57':'mainform:j_id57','ajaxSingle':'mainform:corradresvraag'} ,'actionUrl':'/abf-sf-web/pages/instroom/adres.xhtml','similarityGroupingId':'mainform:j_id57','control':this} )" type="radio">
  <label for="mainform:corradresvraag:1"> ja</label>
</td>
</tr>
</tbody></table>
</fieldset>

Enkel de javascript in het event lijkt wat vreemd, en helemaal gelukkig met de keuze voor een tabel ben ik niet, maar voor de rest is het keurige en goed stijlbare html.

Uiteindelijk is het zelfs zo dat we voor de webrichtlijnen van de overheid ongeveer een score van 95% halen.op dit moment.

Nou, ik doe t er niet voor om de redenen die je zelf al aangeeft (form in een tabel, vreselijke JS code erin). Ik werk sinds een jaartje in Zend Framework (OO) en bevalt me echt uitstekend en heb volledige controle over al mn output zoals dat ook nodig is om lastige designs om te krijgen in HTML/CSS.

[Janoz]

Nee, er is niet over nagedacht. Dat is juist het hele punt. Het belangrijkste principe van OO is nu juist dat je de verantwoordelijkheden zo veel mogelijk containt op de plekken waar ze horen. Een superclass zou verantwoordelijk moeten zijn voor de juiste initialisatie van zichzelf. Bij PHP is het nu echter zo dat die verantwoordelijkheid wordt gelegd bij de child class. Het is dus mogelijk dat je een instantie aanmaakt waarvan zijn superclass zich nooit heeft kunnen initializeren. Bij php kun je dus by design je syntactisch correcte code in een illegale state krijgen!

Verder ondersteund PHP helemaal geen meerdere constructors dus valt er weinig te kiezen (weer een WTF)

In bijna alle andere OO talen zie je dat er altijd impliciet een super() call gedaan wordt, tenzij je zelf een (specifieke) constructor van je superclass aanroept. Java geeft bijvoorbeeld gewoon een compile error wanneer je een class extend die geen parameterloze constructor heeft. Je zult dan zelf expliciet aan moeten geven welke constructor je van de parent aan wilt roepen.

[Janoz]

Cartman! schreef op vrijdag 27 maart 2009 @ 15:14:
[...]

Nou, ik doe t er niet voor om de redenen die je zelf al aangeeft (form in een tabel, vreselijke JS code erin). Ik werk sinds een jaartje in Zend Framework (OO) en bevalt me echt uitstekend en heb volledige controle over al mn output zoals dat ook nodig is om lastige designs om te krijgen in HTML/CSS.

Ik zeg dat het javascript alleen wat vreemd lijkt. Het is echter gewoon maar 1 functie aanroep met gegenereerde parameters. Ik snap niet wat daar vreselijk aan is. De code is gewoon netjes. Misschien is enkel het javascript lastig human readable, maar daarvoor is het ook niet bedoeld. De 'human readableness' zit hem juist in het stukje code dat ik daarboven neerzet. Enkel een a4j tag die bij event X van hetgeen waar hij bij staat een reRender actie op element Y aanroept. Veel duidelijker zul je het niet krijgen. De uiteindelijk gerenderde HTML is een keurig nette site die middels AJAX een prettige gebruikers ervaring verzorgt, zonder dat de site onwerkbaar wordt wanneer javascript uitstaat.

De tabel, dat is misschien nog iets, maar zoals eerder al aangegeven, je kunt je eigen renderer schrijven die daar andere html voor genereerd.


Ik blijf er echter bij dat het bovenstaande stukje formulier html code 1000x beter is dan wat je gemiddeld als handgemaakte html meuk tegenkomt.

[netvor]

Eens. En alles (ook de containing table) heeft een logische ID, wat handig is bij het automatisch verwerken van pagina's. Ikzelf schrijf vaak automatische tests met Selenium, en in ASP.NET apps moet je vaak lelijke hacks uithalen (lees: XPath) omdat de gegenereerde ID's niet altijd constant zijn en per build kunnen verschillen.

Wat betreft de table: laten we nou even niet een nog langer lopende discussie boven water halen... Dan zouden we het net zo goed meteen over Vi vs. Emacs vs. Nano kunnen hebben.

[MBV]

.oisyn schreef op vrijdag 27 maart 2009 @ 15:09:

En PHP kent geen multiple class inheritance.

Java ook niet.

Janoz schreef op vrijdag 27 maart 2009 @ 15:21:
Verder ondersteund PHP helemaal geen meerdere constructors dus valt er weinig te kiezen (weer een WTF)

*kadoenk* *klimt op stoel* WTF?!
Dus je moet zoiets doen:

PHP:

__construct() {
  switch (func_num_args()) {
  ...
  }
}

En ik snap best dat automagisch gegenereerde en opgemaakte code tables gebruikt: dat is minder gemakkelijk te beïnvloeden van 'buitenaf': als je een fout maakt in een ander stuk HTML is de kans groter dat de table heel blijft.

[Voutloos]

Tja, voor meerdere constructors en polymorfisme enzo heb je al uberhaupt al scalar type hints nodig en dat gaat er al uberhaupt nooit komen.
_{(Maar array en object hints zijn er grappig genoeg wel )}

[MBV]

Het zou al aardig zijn als je op het aantal argumenten kan checken, vaak is meer niet eens nodig, toch?

[Cartman!]

Janoz schreef op vrijdag 27 maart 2009 @ 15:26:
[...]

Ik zeg dat het javascript alleen wat vreemd lijkt. Het is echter gewoon maar 1 functie aanroep met gegenereerde parameters. Ik snap niet wat daar vreselijk aan is. De code is gewoon netjes. Misschien is enkel het javascript lastig human readable, maar daarvoor is het ook niet bedoeld. De 'human readableness' zit hem juist in het stukje code dat ik daarboven neerzet. Enkel een a4j tag die bij event X van hetgeen waar hij bij staat een reRender actie op element Y aanroept. Veel duidelijker zul je het niet krijgen. De uiteindelijk gerenderde HTML is een keurig nette site die middels AJAX een prettige gebruikers ervaring verzorgt, zonder dat de site onwerkbaar wordt wanneer javascript uitstaat.

De tabel, dat is misschien nog iets, maar zoals eerder al aangegeven, je kunt je eigen renderer schrijven die daar andere html voor genereerd.


Ik blijf er echter bij dat het bovenstaande stukje formulier html code 1000x beter is dan wat je gemiddeld als handgemaakte html meuk tegenkomt.

Ik hou met HTML altijd los van mn JS omdat ik vind dat dit niet door elkaar hoort te staan. Zie het als een laag bovenop HTML. Is een kwestie van persoonlijke smaak misschien maar ik vind het een potje zoals het nu gegenereerd wordt, w3c valid of niet.

[? ?]

..

[ Voor 100% gewijzigd door ? ? op 25-01-2013 09:47 ]

[Cartman!]

Overigens denk ik dat we met zn alleen erg offtopic gaan, misschien (als iemand dit wil) deze discussie voortzetten in n nieuw topic?

[.oisyn]

MBV schreef op vrijdag 27 maart 2009 @ 16:07:
[...]

Java ook niet.

Klopt, what's your point?

[Janoz]

Cartman! schreef op vrijdag 27 maart 2009 @ 16:21:
Is een kwestie van persoonlijke smaak misschien maar ik vind het een potje zoals het nu gegenereerd wordt, w3c valid of niet.

Je zou natuurlijk een stuk javascript onderaan je pagina kunnen laten genereren die je dom gaat doorlopen en zo overal eventlisteners aan plakt, maar is dat nu echt zoveel netter en cleaner dan 1 enkele functioncall in een onclick property? Zeker wanneer dat alleen maar terugkomt in de gegenereerde code?

Maar goed, stel ik het anders. Laat jij nu eens zien hoe jij een meerkeuze vraag met twee mogelijke antwoorden rendert, waarbij de gemaakte keuze vervolgens een deel van het formulier aanpast middels AJAX.

Het enige wat je hoeft te laten zien is het stuk zoals de developer het ziet en het stuk zoals het uiteindelijk in de HTML terecht komt. Van het AJAX deel hoef je alleen maar te laten zien hoe het gestart wordt. De daadwerkelijke code voor de ajax call en het deel dat zichzelf aanpast kun je achterwege laten.

[mithras]

.oisyn schreef op vrijdag 27 maart 2009 @ 16:39:
[...]

Klopt, what's your point?

Dat het php bashen vanwege het ontbreken enkele features niet bijster slim is. In andere talen kunnen die features ook missen en daarom is php niet per sé de grote boze wolf.

Wanneer ontwerpkeuzes niet goed zijn overwogen, ok. Dat is een goed punt. Maar het missen van features zoals multiple class inheritance lijkt me nu niet helemaal een reden om een taal 'goed' of 'slechts' te noemen

[kenneth]

mithras schreef op vrijdag 27 maart 2009 @ 16:47:
[...]
Dat het php bashen vanwege het ontbreken enkele features niet bijster slim is. In andere talen kunnen die features ook missen en daarom is php niet per sé de grote boze wolf.

Eh, dat was het hele punt niet.

Het ging erom dat de features die WEL geimplementeerd waren regelmatig gebrekkig werden geimplementeerd. Dat PHP geen multiple inheritance ondersteunt is niet het probleem, maar dat het ondanks single inheritance (blijkbaar) niet standaard de constructor van de superklasse aanroept.

[Janoz]

Het multiple Inheritance deel van zijn opmerking was niet een 'bash', maar een reactie op 'Hoe wil je anders multiple inheritance implementeren?'.

Multiple inheritance werd als verdediging gebruikt voor een ontwerpkeuze, maar php ondersteund helemaal geen multiple inheritance.

[mithras]

kenneth schreef op vrijdag 27 maart 2009 @ 16:53:
[...]
Eh, dat was het hele punt niet.

Dat haal ik wel uit .oisyn in "[alg] Slechtste programmeervoorbeelden d...". Een nieuwe alinea in een php discussie met die oneliner noem ik bashen Als het niet zo is, verbeter me hoor

Het ging erom dat de features die WEL geimplementeerd waren regelmatig gebrekkig werden geimplementeerd. Dat PHP geen multiple inheritance ondersteunt is niet het probleem, maar dat het ondanks single inheritance (blijkbaar) niet standaard de constructor van de superklasse aanroept.

Ik ben niet de meest geleerde programmeur en heb alles maar mezelf aangeleerd. Toch denk ik gewoon dat (in eerste instantie Janoz en nu jij) jullie dit bedoelen: mithras in "[alg] Slechtste programmeervoorbeelden d..."

Janoz schreef op vrijdag 27 maart 2009 @ 16:54:
Het multiple Inheritance deel van zijn opmerking was niet een 'bash', maar een reactie op 'Hoe wil je anders multiple inheritance implementeren?'.

Multiple inheritance werd als verdediging gebruikt voor een ontwerpkeuze, maar php ondersteund helemaal geen multiple inheritance.

Ah, ok. My fault

Sowieso is deze discussie overrated. Het boeit imho geen zak of je php wel of niet aardig vind. Je gebruikt het wel of niet, dat is een eigen keuze en daarmee is de zaak redelijk afgedaan (simpel gezegd).

[ Voor 25% gewijzigd door mithras op 27-03-2009 16:57 ]

[Cartman!]

Janoz schreef op vrijdag 27 maart 2009 @ 16:44:
[...]
Maar goed, stel ik het anders. Laat jij nu eens zien hoe jij een meerkeuze vraag met twee mogelijke antwoorden rendert, waarbij de gemaakte keuze vervolgens een deel van het formulier aanpast middels AJAX.

Daar heb ik natuurlijk geen voorbeeld van bij de hand. Maar ik pak inderdaad altijd ondomready/onload de uitbreidingen met JS beet om zoals jouw voorbeeld een formulier dynamisch te maken. Ik vind die scheiding netjes, blijkbaar is dat een kwestie van smaak dan.

[.oisyn]

.edit: bliep, ik moet eerst verder lezen, dan replyen

[ Voor 124% gewijzigd door .oisyn op 27-03-2009 17:12 ]

[Cartman!]

Overigens denk ik dat we er toch niet gaan uitkomen omdat ieder simpelweg een eigen voorkeur heeft. Ik ben het ook wel mee eens dat er dingen dom gemaakt zijn door het PHP devteam maar dat weerhoudt mij er niet van om er dagelijks mee te werken of ik heb er mee leren werken.