Oh dat is niet de reden dat JavaScript, maar vooral PHP zulke beroerde talen zijn hoor.quote:
Beste van twee werelden door Nederlands bedrijfquote:Op zondag 15 maart 2015 17:26 schreef Monolith het volgende:
[..]
Oh dat is niet de reden dat JavaScript, maar vooral PHP zulke beroerde talen zijn hoor.
Bijkomend voordeel is dat je diffs kleiner blijven omdat je geen regel wijzigt door er alleen een komma aan toe te voegen als je een extra regel aan de array wilt toevoegen. En, zeker als je met een groter team werkt, is het wel handig dat git blame de juiste persoon bij en de juiste reden van een wijziging laat zien.quote:Op zondag 15 maart 2015 18:54 schreef KomtTijd... het volgende:
Ik vind die komma aan het einde van een array ideaal! Als 'ie ontbreekt voeg ik hem juist vaak toe. En ik vind het ook moeilijk irritant dat je 'm in SQL niet mag plaatsen.
Het maakt het uitbreiden van arrays een stuk makkelijker en de kans dat je een syntax error krijgt omdat je een komma vergeten bent in de regel boven de regel die je toegevoegd hebt, veel kleiner.
Zit je zo vaak handmatig JSON-files te schrijven, dan?quote:Op zondag 15 maart 2015 20:24 schreef slacker_nl het volgende:
Ow ja, en in JSON mag je geen single quotes gebruiken en mag je ook geen trailing , gebruiken. HAAAAAAT (idem voor SQL, haaaaat). Trailing comma == bliss,
Ja, chef data bag files zijn JSON.quote:Op zondag 15 maart 2015 20:39 schreef Tijn het volgende:
[..]
Zit je zo vaak handmatig JSON-files te schrijven, dan?
als je je API zit te testen wil dat best nog wel eens voorkomen ja. Maar van JSON waardeer ik het wel weer dat het flink strict is, voor een transport protocol heeft dat absoluut voordelen.quote:Op zondag 15 maart 2015 20:39 schreef Tijn het volgende:
[..]
Zit je zo vaak handmatig JSON-files te schrijven, dan?
Gewoon terecht. Die trailing komma is voor mensen met een komma-fetish.quote:Op zondag 15 maart 2015 20:24 schreef slacker_nl het volgende:
Ow ja, en in JSON mag je geen single quotes gebruiken en mag je ook geen trailing , gebruiken. HAAAAAAT (idem voor SQL, haaaaat). Trailing comma == bliss,
Het is een data format, geen transport protocol.quote:Op zondag 15 maart 2015 20:43 schreef KomtTijd... het volgende:
[..]
als je je API zit te testen wil dat best nog wel eens voorkomen ja. Maar van JSON waardeer ik het wel weer dat het flink strict is, voor een transport protocol heeft dat absoluut voordelen.
Gewoon terecht. Die trailing komma is voor mensen met een komma-fetish.quote:Op zondag 15 maart 2015 20:44 schreef robin007bond het volgende:
[ afbeelding ] Op zondag 15 maart 2015 20:24 schreef slacker_nl het volgende:
Ow ja, en in JSON mag je geen single quotes gebruiken en mag je ook geen trailing , gebruiken. HAAAAAAT (idem voor SQL, haaaaat). Trailing comma == bliss,
1 2 3 4 5 6 7 8 9 10 | XXX::Foo->new( foo => bar, ); of XXX::Foo->new( foo => bar, baz => fubar, ); |
Inderdaad. HTTP is een transport protocol, maar JSON niet.quote:Op zondag 15 maart 2015 20:48 schreef Monolith het volgende:
[..]
Het is een data format, geen transport protocol.
Je hebt gelijk maar je begrijpt wat ik bedoelquote:Op zondag 15 maart 2015 20:48 schreef Monolith het volgende:
[..]
Het is een data format, geen transport protocol.
Natuurlijk begrijp ik dat, maar op zich maakt het niet zoveel uit of je nou wel of niet dat soort constructies toestaat. Als de specs maar duidelijk en ondubbelzinnig zijn.quote:Op zondag 15 maart 2015 21:04 schreef KomtTijd... het volgende:
[..]
Je hebt gelijk maar je begrijpt wat ik bedoel
Oh, ik bedoelde niet als je een array meegeeft als parameter van een functie (de vraag is alleen of je niet liever een object meegeeft in plaats van een array, maar dat terzijde). De builder-pattern vind ik eerlijk gezegd geschikter dan een functie maken die allerlei config-opties vereist in een array.quote:Op zondag 15 maart 2015 20:52 schreef slacker_nl het volgende:
[..]
Ik heb regelmatig:
[ code verwijderd ]
Plus als ik alles ga sorten en zulks, breekt er niks omdat de komma plots verdwenen is midden in m'n lijst.
1 2 | function blabla(x, y,) { } |
Meh, dan krijg je weer dat parsers foutcorrectie gaan doen enzo en protocollen die onterecht rekenen op die foutcorrectie en wordt de boel allemaal omslachtiger en trager. JSON is juist zo lekker lean en efficiėnt, houden zo. Heb volgens mij ooit ergens gelezen dat de JSON_ functies van PHP sneller zijn dan haar eigen serialize() en unsereialize().quote:Op zondag 15 maart 2015 21:11 schreef Monolith het volgende:
[..]
Natuurlijk begrijp ik dat, maar op zich maakt het niet zoveel uit of je nou wel of niet dat soort constructies toestaat. Als de specs maar duidelijk en ondubbelzinnig zijn.
Een class serializen? Neem aan dat je een object bedoelt. En ja dat lijkt me nogal logisch toch? Waarom zou je ooit een private property willen exporteren? Als dat de bedoeling is kan het haast niet de bedoeling zijn dat die property private is.quote:Op zondag 15 maart 2015 21:32 schreef robin007bond het volgende:
Over JSON in PHP gesproken. Als je een klasse wil serializen naar JSON, dan moeten de properties per se public zijn, want anders worden ze niet in de JSON opgenomen.
Uiteraard bedoel ik een object.quote:Op zondag 15 maart 2015 21:35 schreef KomtTijd... het volgende:
[..]
Een class serializen? Neem aan dat je een object bedoelt. En ja dat lijkt me nogal logisch toch? Waarom zou je ooit een private property willen exporteren? Als dat de bedoeling is kan het haast niet de bedoeling zijn dat die property private is.
Nee hoor. Als die class de interface JsonSerializable implementeert (en dus een functie jsonSerialize moet hebben) kan de class perfect zelf bepalen wat er wel en hoe naar json omgezet moet worden.quote:Op zondag 15 maart 2015 21:32 schreef robin007bond het volgende:
Over JSON in PHP gesproken. Als je een klasse wil serializen naar JSON, dan moeten de properties per se public zijn, want anders worden ze niet in de JSON opgenomen.
Valt wel mee. Vaak worden de Javabeans conventies gebruikt.quote:Op zondag 15 maart 2015 21:45 schreef KomtTijd... het volgende:
Sja dan wordt het sowieso een moeilijk verhaal want dan wil je ook dat eventuele logica in de accessors uitgevoerd wordt. Als je ingewikkelder objecten wilt serializen kun je beter een wat geavanceerde de serializer library gebruiken zoals jms.
Of je nou named parameters of niet gebruikt, maakt niet uit of je wel/geen objecten gebruikt in je calls.quote:Op zondag 15 maart 2015 21:21 schreef robin007bond het volgende:
[..]
Oh, ik bedoelde niet als je een array meegeeft als parameter van een functie (de vraag is alleen of je niet liever een object meegeeft in plaats van een array, maar dat terzijde). De builder-pattern vind ik eerlijk gezegd geschikter dan een functie maken die allerlei config-opties vereist in een array.
Maar ik bedoelde meer dus dit:
[ code verwijderd ]
Jij zou dat ook echt zo doen?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | sub foo { my ($self, $foo, $bar, undef, $baz,) = @_; } $self->foo($foo, $bar, 'Ignore me', $object->baz); # Deze is ook wel fijn sub foo { my $self = shift; my %named = @_; } $self->foo( foo => $foo_object, baz => $baz_object, ); |
denk dat dit het moet zijn:quote:
1 | DateAdd("m", 2, [Date]) |
Nee, sorry, ik had die spaties alleen hier toegevoegd, omdat het anders niet zichtbaar is op fok!..quote:Op maandag 16 maart 2015 16:43 schreef slacker_nl het volgende:
[..]
denk dat dit het moet zijn:
[ code verwijderd ]
Volgens mij pikt ie de spaties rond "Date" niet.
Nope, ik doe niet aan Access (het is ook wat offtopic voor dit topic overigens).quote:Op dinsdag 17 maart 2015 09:57 schreef Crohnjurist het volgende:
[..]
Nee, sorry, ik had die spaties alleen hier toegevoegd, omdat het anders niet zichtbaar is op fok!..
Maar het werkt dus nog steeds niet, nog een ander idee hoe ik twee maanden kan toevoegen? Misschien een andere functie ipv DateAdd?
Jammer! Nee dat begreep ik al, maar aangezien dit het dichtst in de buurt komt qua topic wat er al is, dacht ik ik vraag het maar gewoon even, voor hetzelfde geld had iemand het wel gewetenquote:Op dinsdag 17 maart 2015 10:02 schreef slacker_nl het volgende:
[..]
Nope, ik doe niet aan Access (het is ook wat offtopic voor dit topic overigens).
Heb hier eerder ook een issue mee gehad, oudere versies van IE vinden het niet leuk, nieuwere vallen hier niet over.quote:Op zondag 15 maart 2015 16:14 schreef Tijn het volgende:
[..]
Nee hoor, in Javascript is het ook geen probleem.
[ code verwijderd ]
Dit werkt gewoon
Moeten het niet single quotes zijn voor de maand aanduiding, dus 'm' in plaats van "m"?quote:Op dinsdag 17 maart 2015 09:57 schreef Crohnjurist het volgende:
[..]
Nee, sorry, ik had die spaties alleen hier toegevoegd, omdat het anders niet zichtbaar is op fok!..
Maar het werkt dus nog steeds niet, nog een ander idee hoe ik twee maanden kan toevoegen? Misschien een andere functie ipv DateAdd?
Mwah, t is wel redelijk specifieke access syntax waar je problemen mee hebt. Ik zou een topic openen of kijken of het in een algemeen MS Office topic kan (als die er is)quote:Op dinsdag 17 maart 2015 10:03 schreef Crohnjurist het volgende:
[..]
Jammer! Nee dat begreep ik al, maar aangezien dit het dichtst in de buurt komt qua topic wat er al is, dacht ik ik vraag het maar gewoon even, voor hetzelfde geld had iemand het wel geweten
Mmm ik denk dat dat het probleem is, het veld genaamd Date is niet altijd ingevuld. Maar voor de dossiers die wel ingevuld zijn probeer ik dus twee maanden erbij te krijgen. Dit is dus niet mogelijk?quote:Op dinsdag 17 maart 2015 13:51 schreef Monolith het volgende:
[..]
Moeten het niet single quotes zijn voor de maand aanduiding, dus 'm' in plaats van "m"?
Verder neem ik aan dat je een veld genaamd Date hebt en dat daar altijd een geldige datumwaarde in zit?
Je kunt vast een 'doe dit alleen als het veld niet leeg is' constructie hanteren, maar ik heb echt al meer dan 10 jaar niets met Access gedaan, dus dat zou ik niet direct weten.quote:Op dinsdag 17 maart 2015 14:11 schreef Crohnjurist het volgende:
[..]
Mmm ik denk dat dat het probleem is, het veld genaamd Date is niet altijd ingevuld. Maar voor de dossiers die wel ingevuld zijn probeer ik dus twee maanden erbij te krijgen. Dit is dus niet mogelijk?
Haha oké, in ieder geval bedankt tot zover!quote:Op dinsdag 17 maart 2015 14:29 schreef Monolith het volgende:
[..]
Je kunt vast een 'doe dit alleen als het veld niet leeg is' constructie hanteren, maar ik heb echt al meer dan 10 jaar niets met Access gedaan, dus dat zou ik niet direct weten.
quote:Op woensdag 18 maart 2015 12:46 schreef n8n het volgende:
werkt zoiets met php (en zo ja, wat is de juiste markup)?
$var = ( isset( $this-when-true ) : $or-else );
1 | $var = ( isset($test-variable) ? $this-when-true : $or-else ); |
$var = ( isset($this-when-true) ? $this-when-true : $or-else );quote:
Veel korter dan een ternary operator krijg je een if-then-else statement niet. 'this-when-true' slaat ook niet ergens op. Wat je eigenlijk wilt is een 'default-if-null'-constructie.quote:Op woensdag 18 maart 2015 12:57 schreef n8n het volgende:
[..]
$var = ( isset($this-when-true) ? $this-when-true : $or-else );
Zou zo zijn dan, is ook wat ik nu heb, ik hoopte dat het nog korter (droger) kon omdat ik het zo zinloos vind om eerst te checken of iets bestaat en dan apart de inhoud toe te wijzen. Mooier zou zijn als je $var = ( $this-when-true || false ); kon doen zonder dat php over z'n nek gaat omdat de variable niet bestaat.
Bedankt in elk geval, mysterie opgelost, kan ik weer verder
Volgens mij krijg je dan alsnog een notice als je een niet-gedefinieerde variabele aan die functie meegeeft.quote:Op woensdag 18 maart 2015 13:21 schreef Monolith het volgende:
Als je dat echt kort wilt, dan maak je er toch gewoon een functie van, zodat je $var = defaultIfNotSet(originalValue, defaultValue) kan hanteren?
Dat wel ja, maar ik weet niet of het erg is.quote:Op woensdag 18 maart 2015 13:30 schreef mstx het volgende:
[..]
Volgens mij krijg je dan alsnog een notice als je een niet-gedefinieerde variabele aan die functie meegeeft.
Wat is er precies slecht aan?quote:Op woensdag 18 maart 2015 13:38 schreef Monolith het volgende:
[..]
Dat wel ja, maar ik weet niet of het erg is.
Het geeft wel weer aan hoe enorm slecht PHP in elkaar steekt.
Het feit dat isset een functie is als elke andere. Echter, impliciet zit erin verborgen dat een notice wordt onderdrukt op het moment dat je een ongedefinieerde variabele als parameter aan deze specifieke functie meegeeft. Als je dit per se op deze manier wilt doen, dan moet je er een language construct van maken, geen functie met verborgen bij-effecten.quote:
quote:Op woensdag 18 maart 2015 13:49 schreef Monolith het volgende:
[..]
Het feit dat isset een functie is als elke andere. Echter, impliciet zit erin verborgen dat een notice wordt onderdrukt op het moment dat je een ongedefinieerde variabele als parameter aan deze specifieke functie meegeeft. Als je dit per se op deze manier wilt doen, dan moet je er een language construct van maken, geen functie met verborgen bij-effecten.
Ik ben sowieso al geen voorstander van het idee dat je variabelen kunt hanteren zonder dat je überhaupt weet of ze gedeclareerd zijn (los van de vraag of ze een waarde hebben), maar dat is een langslepend gevolg van het feit dat PHP van oorsprong een simpel scripttaaltje was met allerlei brakke globals.
Oh ja, dat klopt. Het staat alleen in de docs onder 'variable handling function'.quote:Op woensdag 18 maart 2015 14:12 schreef KomtTijd... het volgende:
[..]Isset() ķs een language construct.
Dat is erg?quote:Op woensdag 18 maart 2015 14:23 schreef Monolith het volgende:
[..]
Maar dan nog is het feit dat er een notice is voor het gebruik van niet gedefinieerde variabelen
Je quote de halve zin, maar ook een notice bij een niet gedefinieerde variabele is echt een oplossing van niets. Of je geeft een exception / error of niet. Nu heb je dus afhankelijk van het niveau van error_reporting onverwachte bij-effecten. Het feit dat je dan weer met een @ operator die notice moet gaan onderdrukken maakt het nog erger.quote:
Van notices hebben mensen wel degelijk last. Zoals ik zeg is dat een bij-effect. Zeker wanneer mensen de code gebruiken in HTML, kunnen de gebruikers het te zien krijgen, wat doorgaans niet wenselijk is. Wanneer je met gecompileerde talen werkt zijn warnings / notices niet zo'n probleem. Prima te hanteren wanneer er bijvoorbeeld deprecated zaken worden gehanteerd. Runtime allerhande notices gaan uitspugen is nooit wenselijk.quote:Op woensdag 18 maart 2015 14:58 schreef Tijn het volgende:
Natuurlijk heb je helemaal gelijk dat PHP geen doordacht design heeft en in de loop der jaren enorm uit de kluiten is gegroeid, zonder dat dat aanvankelijk voorzien was. Maar ik vind niet dat er wat betreft ongedefinieerde variabelen nou echt zoveel mis is.
Je zegt het zelf al: geef als taal een error of niet. Nou, in het geval van PHP is het antwoord duidelijk: het gebruik van een ongedefinieerde variabele is geen enkel probleem. Dat je er een notice over krijgt, is een poging van PHP om hun gebruikers een beetje op te voeden, dat is alles. Maar daar heeft toch niemand last van verder?
1 2 3 | <?php ( isset($_GET[$table[$i]) ? $$table[$i] = new data($table[$i]) : false ); ?> |
1 2 3 | <?php $page->when('published')->take(-4); // laatste 4 gepubliceerde items van deze pagina ?> |
Ik kijk eerst of de table-name (mogelijk met een hard-coded/cached array) een match heeft met de url, als dat waar ik is pak ik de tabel met een query en hang deze aan een nieuwe instance van mn data class. de waarde van de get-key gebruik ik om de query te limiteren voor wat relevant is aan die pagina.quote:Op donderdag 19 maart 2015 10:36 schreef KomtTijd... het volgende:
Dat kun je toch veel beter in je query afhandelen? Dit lijkt me performance-wise niet bepaald optimaal. En als je tabellen wat groter worden ga je geheid uit je geheugen limiet lopen.
Dat bewijst zonder dat ik weet wat dat is, de noodzaak voor een ORMquote:Op donderdag 19 maart 2015 10:54 schreef KomtTijd... het volgende:
Je bent dus min of meer je eigen ORM aan het uitvinden? Daar is op zich niets mis mee nee.
Natuurlijk, maar lijkt me relevant dat hij daar even rekening mee houdt.quote:Op donderdag 19 maart 2015 10:56 schreef KomtTijd... het volgende:
[..]
riep daar iemand prepared statements?
SQL injectie kan met iedere query waar user input in staat. Ook met select queries. Daarom nooit user input direct in je query verwerken.quote:Op donderdag 19 maart 2015 10:57 schreef n8n het volgende:
[..]
Dat bewijst zonder dat ik weet wat dat is, de noodzaak voor een ORM![]()
Injecteren? Er gaat niks via deze weg 'omhoog', de data die losgetrokken kan worden is al openbaar. Verder nog hiaten waar ik geen idee van heb? Weet alleen dat ik PDO moet gebruiken en ALLES moet valideren wat omhoog gaat.
user input zoals een get varible zoals /?page=malafide-code. Dat vang je af met pdo/prepared statements?quote:Op donderdag 19 maart 2015 11:02 schreef KomtTijd... het volgende:
[..]
SQL injectie kan met iedere query waar user input in staat. Ook met select queries. Daarom nooit user input direct in je query verwerken.
En kijk ook eens naar bestaande ORM libs, zoals doctrine of redbean.
Klopt. Enige punt is dat je in jouw geval moet uitkijken voor /?malafide-code=waarde aangezien je ook min of meer dynamische tabelnamen wilt hebben op basis van de naam van request parameters. Gelukkig gebruik je de tabel en niet de request parameter daarvoor, dus dat moet goed gaan, maar het is wel iets waar je mee moet uitkijken. Helemaal omdat tabelnamen niet middels prepared statements in een query kunnen worden gestopt, dus daar ben je zelf verantwoordelijk voor het voorkomen van SQL injection.quote:Op donderdag 19 maart 2015 11:06 schreef n8n het volgende:
[..]
user input zoals een get varible zoals /?page=malafide-code. Dat vang je af met pdo/prepared statements?
de table names zet ik in een var:quote:Op donderdag 19 maart 2015 11:32 schreef Monolith het volgende:
[..]
Klopt. Enige punt is dat je in jouw geval moet uitkijken voor /?malafide-code=waarde aangezien je ook min of meer dynamische tabelnamen wilt hebben op basis van de naam van request parameters. Gelukkig gebruik je de tabel en niet de request parameter daarvoor, dus dat moet goed gaan, maar het is wel iets waar je mee moet uitkijken. Helemaal omdat tabelnamen niet middels prepared statements in een query kunnen worden gestopt, dus daar ben je zelf verantwoordelijk voor het voorkomen van SQL injection.
1 2 3 4 | <?php $tables = "show tables from $db"; //of $tables = ['table1', 'table2']; ?> |
Ow perlquote:Op woensdag 18 maart 2015 13:21 schreef Monolith het volgende:
[..]
Veel korter dan een ternary operator krijg je een if-then-else statement niet. 'this-when-true' slaat ook niet ergens op. Wat je eigenlijk wilt is een 'default-if-null'-constructie.
Als je dat echt kort wilt, dan maak je er toch gewoon een functie van, zodat je $var = defaultIfNotSet(originalValue, defaultValue) kan hanteren?
1 2 3 4 | $foo //= "bar" ; # is hetzelfde als $foo = defined $foo ? $foo : "bar" ; |
quote:
quote:Op woensdag 18 maart 2015 13:21 schreef Monolith het volgende:
[..]
Veel korter dan een ternary operator krijg je een if-then-else statement niet. 'this-when-true' slaat ook niet ergens op. Wat je eigenlijk wilt is een 'default-if-null'-constructie.
Als je dat echt kort wilt, dan maak je er toch gewoon een functie van, zodat je $var = defaultIfNotSet(originalValue, defaultValue) kan hanteren?
1 | $eenVariabele = $dezeWaardeAlsHijBestaat ?? $andersDit; |
Je kan PHP 7 al uitproberen dan? De meest recente versie die gebruikt kan worden, is bij ons nog steeds PHP 5.6quote:
Dat hoeft toch niet perse? Specs kunnen al lang voor enige release bekend zijn. Maar volgens mij wordt er al best lang gesleuteld aan php7 dus je kunt vast wel ergens een dev build vandaan halen als je zou willen.quote:Op zaterdag 21 maart 2015 22:05 schreef Robuustheid het volgende:
[..]
Je kan PHP 7 al uitproberen dan? De meest recente versie die gebruikt kan worden, is bij ons nog steeds PHP 5.6
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |