abonnement Unibet Coolblue
pi_150668751
quote:
0s.gif Op zondag 15 maart 2015 17:13 schreef mstx het volgende:

[..]

C# en C++
Geeft de compiler ook geen warnings?
pi_150668886
quote:
10s.gif Op zondag 15 maart 2015 16:45 schreef mstx het volgende:

[..]

[ afbeelding ]

[ afbeelding ]

:W
Oh dat is niet de reden dat JavaScript, maar vooral PHP zulke beroerde talen zijn hoor.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_150669306
quote:
0s.gif Op zondag 15 maart 2015 17:13 schreef mstx het volgende:

[..]

C# en C++
In C met GCC en -Wall wordt er ook geen foutmelding weergeven. :o
pi_150671840
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.
pi_150673760
Dat kan ik echt niet bevatten. Het is voor mij echt... Onbegrijpelijk.

:{
pi_150674614
quote:
1s.gif 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.
Beste van twee werelden door Nederlands bedrijf :+
http://www.php-cpp.com
When the student is ready, the teacher will appear.
When the student is truly ready, the teacher will disappear.
  zondag 15 maart 2015 @ 20:24:07 #157
187069 slacker_nl
Sicko pur sang
pi_150674754
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,
In theory there is no difference between theory and practice. In practice there is.
pi_150675075
quote:
14s.gif 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.
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.
  zondag 15 maart 2015 @ 20:39:36 #159
12221 Tijn
Powered by MS Paint
pi_150675620
quote:
0s.gif 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,
Zit je zo vaak handmatig JSON-files te schrijven, dan? :?
  zondag 15 maart 2015 @ 20:42:28 #160
187069 slacker_nl
Sicko pur sang
pi_150675781
quote:
5s.gif Op zondag 15 maart 2015 20:39 schreef Tijn het volgende:

[..]

Zit je zo vaak handmatig JSON-files te schrijven, dan? :?
Ja, chef data bag files zijn JSON.
In theory there is no difference between theory and practice. In practice there is.
pi_150675831
quote:
5s.gif 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.
pi_150675899
quote:
0s.gif 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,
Gewoon terecht. Die trailing komma is voor mensen met een komma-fetish.

Plus het gaat me om het principe dat het een scheidingsteken is voor elementen. Je gaat toch ook niet achter parameters een extra komma zetten voor het geval de methode een extra parameter krijgt?

[ Bericht 5% gewijzigd door #ANONIEM op 15-03-2015 20:57:33 ]
pi_150676087
quote:
14s.gif 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.
Het is een data format, geen transport protocol.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
  zondag 15 maart 2015 @ 20:52:05 #164
187069 slacker_nl
Sicko pur sang
pi_150676323
quote:
1s.gif 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,
Gewoon terecht. Die trailing komma is voor mensen met een komma-fetish.

Plus het gaat me om het principe dat het een scheidingsteken is voor elementen. Je gaat toch ook niet achter parameters een extra komma zetten voor het geval de methode een extra parameter krijgt?
[/quote]

jawel.

Ik heb regelmatig:
1
2
3
4
5
6
7
8
9
10
XXX::Foo->new(
    foo => bar, 
);

of 

XXX::Foo->new(
    foo => bar, 
    baz => fubar,
);

Plus als ik alles ga sorten en zulks, breekt er niks omdat de komma plots verdwenen is midden in m'n lijst.
In theory there is no difference between theory and practice. In practice there is.
pi_150676661
quote:
1s.gif Op zondag 15 maart 2015 20:48 schreef Monolith het volgende:

[..]

Het is een data format, geen transport protocol.
Inderdaad. HTTP is een transport protocol, maar JSON niet.
pi_150677072
quote:
1s.gif 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 bedoel :P
pi_150677483
quote:
14s.gif Op zondag 15 maart 2015 21:04 schreef KomtTijd... het volgende:

[..]

Je hebt gelijk maar je begrijpt wat ik bedoel :P
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.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
pi_150677888
quote:
0s.gif 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.
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:

1
2
function blabla(x, y,) {
}

Jij zou dat ook echt zo doen? :o
pi_150678313
quote:
1s.gif 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.
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().
pi_150678403
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. :')
pi_150678554
quote:
0s.gif 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. :')
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.
pi_150678620
quote:
1s.gif 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.
Uiteraard bedoel ik een object.

Maar dat vind ik niet heel logisch. Het is namelijk goed gebruik dat je accessor-methodes gebruikt voor velden in plaats van de variabelen public te maken.
pi_150679051
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.
pi_150681747
quote:
0s.gif 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. :')
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.
pi_150681982
quote:
14s.gif 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.
Valt wel mee. Vaak worden de Javabeans conventies gebruikt.
In Java heb je bovendien nog weer transient voor zaken die niet geserialized moeten worden.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
abonnement Unibet Coolblue
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')