De Devschuur Coffee Corner - Iteratie ➓

[CodeCaster]

F.West98 schreef op maandag 29 augustus 2016 @ 02:59:
Wie verzint dat nou weer... Definieer je voor je IIS extension een XML Schema, met ergens een uint. Gebruik je in de code keurig overal een uint, alles goed en wel. Installeren, testen, draaien: InvalidCastException...
Blijkt die uint uit de config dus als long geïnterpreteerd te worden in C#?! Geen idee of dat nou documented ergens is, maar ik vind het iig heel erg vaag. En zonde van dat halve uur die mij dat gekost heeft.

Zou niet moeten als je een klasse uit een XSD genereert:

quote: https://msdn.microsoft.co...y/xa669bew(v=vs.110).aspx

xs:unsignedInt -> UInt32

[DevWouter]

HMS schreef op maandag 29 augustus 2016 @ 10:43:
Grote XML configs roepen bij mij ook nog steeds nachtmerries over Java op

Fixed that for you

[Blue-eagle]

Zucht. Nieuwe baan. Intake gehad om kennis te maken met het team. Gebruiken ze standaard overal een 2-spaties indentation...

Waarom gebruikt niet iedereen gewoon 1 tab? Dat is 1 character in plaats van 2, en het kan zo breed zijn als je zelf wilt want dat valt gewoon in te stellen.

Twee spaties zijn altijd gewoon maar twee spaties.

Dit irriteert lichtelijk. Het is ongetwijfeld mogelijk om binnen mijn IDE in te stellen dat 2 spaties de indent zijn en dat ze weergegeven mogen worden als 1 tab, en dat ik het fix on-git-push ofzo. Zucht. Gedoe...

[wackmaniac]

https://twitter.com/msavin/status/769521867837276160:

Spaces are a symbol for seperation, tabs are a symbol for indentation. It makes sense to indent code with tabs. Why are devs debating this 🤔

[Merethil]

HMS schreef op maandag 29 augustus 2016 @ 10:43:

[...]


Grote XML configs roepen bij mij ook nog steeds nachtmerries over Java op

Bij mij is 't meer XML in het algemeen. Het is zo... bloated. Superhandig, en veel te groot. Maar goed, de echte nachtmerries kwamen bij mij pas toen ik Excelsheets wilde inlezen/bouwen met Java. 2000 regels in Excel? Prima, ik pak wel even 1 GB aan memory, om een file van ~200 kB te bouwen....... Meh.

[qless]

Ik heb tegenwoordig het liefst JSON als uitwisselingsformaat... XML (al dan niet met SOAP) is nogal....lomp.

En idd xlsx formaat met 1.1 miljoen rows in memory is killing...

[ Voor 23% gewijzigd door qless op 29-08-2016 12:02 ]

[Acid_Burn]

Blue-eagle schreef op maandag 29 augustus 2016 @ 11:27:

Waarom gebruikt niet iedereen gewoon 1 tab? Dat is 1 character in plaats van 2, en het kan zo breed zijn als je zelf wilt want dat valt gewoon in te stellen.

Totdat je met YAML files moet gaan werken, daar mogen geen tabs in

[Alex)]

Fuck tabs, spaties

[.oisyn]

F.West98 schreef op maandag 29 augustus 2016 @ 02:59:
Wie verzint dat nou weer... Definieer je voor je IIS extension een XML Schema, met ergens een uint. Gebruik je in de code keurig overal een uint, alles goed en wel. Installeren, testen, draaien: InvalidCastException...
Blijkt die uint uit de config dus als long geïnterpreteerd te worden in C#?! Geen idee of dat nou documented ergens is, maar ik vind het iig heel erg vaag. En zonde van dat halve uur die mij dat gekost heeft.

De echte vraag is: waarom gebruikte je een uint? Hint: "omdat hij niet negatief kan zijn" is geen valide reden.

[Hatsieflatsie]

wackmaniac schreef op maandag 29 augustus 2016 @ 11:29:
https://twitter.com/msavin/status/769521867837276160:

[...]

Ik gebruik spaties en tabs door elkaar, verschillende spaties zelfs. M'n IDE regelt dat automatisch voor mij conform de codestandaarden die voor iedere taal gelden:




Ik zou echt niet weten of ik tabs of spaces gebruik. En wanneer ik andermans code bewerk, wordt de indentatie ook automatisch geregeld.

[ Voor 20% gewijzigd door Hatsieflatsie op 29-08-2016 13:16 ]

[mbarie]

Development driven testing

[qless]

.oisyn schreef op maandag 29 augustus 2016 @ 12:53:
[...]


De echte vraag is: waarom gebruikte je een uint? Hint: "omdat hij niet negatief kan zijn" is geen valide reden.

Waarom niet? dat kan (zeker in combi met embedded) prima een stuk handiger zijn. Stel dat je (bijv) 0 tot en met 4294967295 moet coderen? dan beter een uint32 dan een int64

[ThomasG]

qless schreef op maandag 29 augustus 2016 @ 13:33:
[...]


Waarom niet? dat kan (zeker in combi met embedded) prima een stuk handiger zijn. Stel dat je (bijv) 0 tot en met 4294967295 moet coderen? dan beter een uint32 dan een int64

Dat is enkel een reden als je exact tot 2^32-1 gaat, bijvoorbeeld als teller voor een bepaalde datastructuur. Maar, daar heb je dan enkel baat bij als je dat in een binair bestandsformaat opslaat. In een XML-bestand kun je net zo goed, of misschien wel beter, een 64-bit integer gebruiken omdat het evenveel ruimte in neemt maar meer flexibiliteit en voordelen heeft. Dat kun je best binnen de applicatie valideren en casten naar een unsigned 32-bit integer. Unsigned integers in heb je niets aan zonder specifieke reden, en dan nog is het vaak een ontwerpfout.

[.oisyn]

qless schreef op maandag 29 augustus 2016 @ 13:33:
[...]


Waarom niet? dat kan (zeker in combi met embedded) prima een stuk handiger zijn. Stel dat je (bijv) 0 tot en met 4294967295 moet coderen? dan beter een uint32 dan een int64

Dan is "omdat hij niet negatief kan zijn" dus niet de reden van die keuze.

Stel je wilt een leeftijd opslaan. Een leeftijd kan niet negatief zijn, maar tevens heeft het geen "last" van het meer gelimiteerde bereik van positieve getallen van een signed int. Is unsigned int dan toch een betere keuze?

Mijns inziens niet. Het niet negatief kunnen zijn is maar een arbitraire limitatie die toevallig opgaat. De gevolgen van het gebruik van een unsigned int zijn echter een stuk groter. Je kunt leeftijden ineens niet meer van elkaar aftrekken, want dan is het verschil in leeftijd tussen Pietje en Henkie ineens 4 miljard in plaats van -6.

Het type unsigned int modeleert niet de abstract wiskundige set van gehele getallen, terwijl iets als leeftijd daar juist wel in valt.

[TheNephilim]

.oisyn schreef op maandag 29 augustus 2016 @ 14:03:
[...]

Dan is "omdat hij niet negatief kan zijn" dus niet de reden van die keuze.

Stel je wilt een leeftijd opslaan. Een leeftijd kan niet negatief zijn, maar tevens heeft het geen "last" van het meer gelimiteerde bereik van positieve getallen van een signed int. Is unsigned int dan toch een betere keuze?

Mijns inziens niet. Het niet negatief kunnen zijn is maar een arbitraire limitatie die toevallig opgaat. De gevolgen van het gebruik van een unsigned int zijn echter een stuk groter. Je kunt leeftijden ineens niet meer van elkaar aftrekken, want dan is het verschil in leeftijd tussen Pietje en Henkie ineens 4 miljard in plaats van -6.

Het type unsigned int modeleert niet de abstract wiskundige set van gehele getallen, terwijl iets als leeftijd daar juist wel in valt.

Daar heb je een punt inderdaad, leeftijd of andere getallen waar je eventueel mee zou willen rekenen. Maar wat is dan een (praktisch) voorbeeld van een veld waarvoor je wél een unsigned integer zou gebruiken?

[F.West98]

.oisyn schreef op maandag 29 augustus 2016 @ 12:53:
[...]


De echte vraag is: waarom gebruikte je een uint? Hint: "omdat hij niet negatief kan zijn" is geen valide reden.

Vooral omdat het een project is dat ik overgenomen heb en dat zo al was.
Ik gok dat het is omdat het een tijdsduur is in ms, die groter kan zijn dan een normale 32-bit integer en het toch op 32-bit systemen moet werken. Ofzo. Denk ik.
Als ik tijd heb ga ik dat hele ding sowieso eens refactoren want het is één grote troep. In de IIS module (in C++) zaten ook tientallen memory leaks overal (constante strings wél alloceren maar dan niet freeen ) dus het is niet de beste kwaliteit code.

[Laurens-R]

F.West98 schreef op maandag 29 augustus 2016 @ 14:20:
[...]
(constante strings wél alloceren maar dan niet freeen )

Sowieso... waarom uberhaubt een memory alloc doen als het een constant string betreft

[.oisyn]

TheNephilim schreef op maandag 29 augustus 2016 @ 14:13:
[...]


Daar heb je een punt inderdaad, leeftijd of andere getallen waar je eventueel mee zou willen rekenen. Maar wat is dan een (praktisch) voorbeeld van een veld waarvoor je wél een unsigned integer zou gebruiken?

Binaire data, geheugenadressen (als int), enums en andere ordinale data (een maand in een datum is eigenlijk ook strict ordinaal). En het zeldzame geval waarbij compactheid van belang is en je toch groter moet kunnen dan signed.

[.oisyn]

Laurens-R schreef op maandag 29 augustus 2016 @ 14:30:
[...]


Sowieso... waarom uberhaubt een memory alloc doen als het een constant string betreft

Waarom überhaupt een custom memory alloc doen in C++

[F.West98]

.oisyn schreef op maandag 29 augustus 2016 @ 14:39:
[...]


Waarom überhaupt een custom memory alloc doen in C++

Don't ask me...
https://github.com/FWest9...le/HSTSIisModule.cpp#L127

[.oisyn]

Ah, COM, dan ontkom je niet aan een "C with classes" coding style. Al was std::unique_ptr<BSTR> handiger geweest, maar dat is vast te modern , al kan ik me voorstellen dat op heel veel plekken de ownership daadwerkelijk getransferred wordt.

[ Voor 25% gewijzigd door .oisyn op 29-08-2016 14:51 ]

[ThomasG]

.oisyn schreef op maandag 29 augustus 2016 @ 14:39:
[...]


Waarom überhaupt een custom memory alloc doen in C++

Omdat je soms voor performance redenen een groot stuk geheugen nodig hebt, wat je later opbreekt?

[.oisyn]

Dan kun je daar std::vector<char> voor gebruiken

[incaz]

Hmm, ik was dat gezeur met $this-> voor elke member-var een beetje zat, en het schijnt dat register_globals ook al niet gewaardeerd meer wordt, dus opperde ik om bepaalde vars die in elke functie gebruikt worden gewoon local te maken met

PHP:

list( $var1, $var2) = $this->initVars()

Dat mocht niet

Maar hoeveel meer evil kun je het krijgen dan

PHP:

// Evil Statement
$result = false;
eval('$result = (' . $evaluate . ') ? true : false;');

if (!$result)
{
    return false;
}

Ik bedoel, dan kan ik ook best mijn list() hebben toch?

(Of gewoon ipv $ een utf8-symbool. Dat je classvars voortaan kunt benaderen met ♡classvar binnen elke functie? Of desnoods €classvar als je in de buurt wilt blijven van het thema van het dollarteken?)

[Laurens-R]

incaz schreef op maandag 29 augustus 2016 @ 15:26:
...
Ik bedoel, dan kan ik ook best mijn list() hebben toch?
...

Dus omdat iets toch al brak is, legimiteerd dat het implementeren van nog meer brakke zaken?

Aan de andere kant... we hebben het over PHP natuurlijk

/me rent weg

[ Voor 3% gewijzigd door Laurens-R op 29-08-2016 15:46 ]

[Skyaero]

incaz schreef op maandag 29 augustus 2016 @ 15:26:
Maar hoeveel meer evil kun je het krijgen dan

PHP:

// Evil Statement
$result = false;
eval('$result = (' . $evaluate . ') ? true : false;');

if (!$result)
{
    return false;
}

Dat dit soort code uberhaupt uitgevoerd kan worden . Het eerste wat ik doe is bij een nieuwe php.ini configuratie een lijst met functies in disable_functions te zetten. En daar valt eval ook onder.

[DevWouter]

Blue-eagle schreef op maandag 29 augustus 2016 @ 11:27:
Waarom gebruikt niet iedereen gewoon 1 tab? Dat is 1 character in plaats van 2, en het kan zo breed zijn als je zelf wilt want dat valt gewoon in te stellen.

Twee spaties zijn altijd gewoon maar twee spaties.

Juist omdat twee spaties dan twee spaties zijn.

Een tab daarin tegen kan het volgende zijn:

• Voeg 2, 3, 4 of 8 spaties in
• Voeg spaties toe tot dat de cursor op een meervoud van 2, 3, 4 of 8 staat
• Ga naar de volgende tab-stop (eerste tab-stop: 4, tweede tab-stop: 8, derde tab-stop: 10 (omdat je left white-space wilt beperken bij nested if's) )
• Voeg spaties toe dat het uitlijnt met een character (curly-brace) op een eerdere regel

Door tabs te verbieden voorkom je ook bij elke non-printable character moet nadenken of het een spatie of een tab is en dat de code bij iedereen hetzelfde eruit ziet... Tenzij ze proportional font gebruiken zoals comic sans.

Overigens als dit het ergste is wat je bijgebleven is heb je of een super-team of focus je te veel op tabs

[RayNbow]

DevWouter schreef op maandag 29 augustus 2016 @ 17:17:
[...]


Juist omdat twee spaties dan twee spaties zijn.

Een tab daarin tegen kan het volgende zijn:

• Voeg 2, 3, 4 of 8 spaties in
• Voeg spaties toe tot dat de cursor op een meervoud van 2, 3, 4 of 8 staat
• Ga naar de volgende tab-stop (eerste tab-stop: 4, tweede tab-stop: 8, derde tab-stop: 10 (omdat je left white-space wilt beperken bij nested if's) )
• Voeg spaties toe dat het uitlijnt met een character (curly-brace) op een eerdere regel

Gelukkig kan een tab ook gewoon een tab zijn.

[.oisyn]

DevWouter schreef op maandag 29 augustus 2016 @ 17:17:
[...]


Juist omdat twee spaties dan twee spaties zijn.

Een tab daarin tegen kan het volgende zijn:

Wat natuurlijk nonsens is in alle bedenkbare text editors, waarbij een tab gewoon een vaste betekenis heeft: uitlijnen naar de volgende kolom dat een veelvoud van N is.

Het voordeel van tab is dat het een duidelijke semantische betekenis heeft dat intentie weergeeft: Een niveau inspringen.

Door tabs te verbieden voorkom je ook bij elke non-printable character moet nadenken of het een spatie of een tab is

Misschien moeten we enters ook maar verbieden en de regels gewoon wrappen na 80 karakters, dwing je ook af dat men niet te lange regels meer maakt

en dat de code bij iedereen hetzelfde eruit ziet...

Wie geeft daar om, really? Ik lees code graag op de manier die ík prettig vind. En dus is het fijn dat ik mijn eigen tabgrootte kan instellen.

[Matis]

Merethil schreef op maandag 29 augustus 2016 @ 09:02:
Nou kan ik dom klinken, maar wat heeft de JRE te maken met C# en IIS?

Hoor ik XML, dan hoor ik Java. Beetje Pavlov

Dat was overigens wel mijn probleem ooit, dat een JRE van 32 bits op een 64 bits host de waardes anders interpreteerde dan een JRE van 32 bits op een 32 bits host.
Iets met ints en longs...

[incaz]

Skyaero schreef op maandag 29 augustus 2016 @ 16:32:
[...]
Dat dit soort code uberhaupt uitgevoerd kan worden . Het eerste wat ik doe is bij een nieuwe php.ini configuratie een lijst met functies in disable_functions te zetten. En daar valt eval ook onder.

Bij nieuwe php.ini's is dat absoluut terecht, maar hoezeer ik ook van leesbare code hou, het om zeep helpen van bestaande code op een plek waar het draait, zonder dat er op dat moment met die code gewerkt wordt, gaat me weer iets te ver.

[Blue-eagle]

DevWouter schreef op maandag 29 augustus 2016 @ 17:17:
[...]


Juist omdat twee spaties dan twee spaties zijn.

Ja, en ik prefereer een indentation ten grootte van 4 spaties, niet 2

Een tab daarin tegen kan het volgende zijn:

• Voeg 2, 3, 4 of 8 spaties in

Precies! Perfect toch! Een tab kan álles zijn wat jij instelt

• Voeg spaties toe tot dat de cursor op een meervoud van 2, 3, 4 of 8 staat

Nee, ik wil gewoon geen spaties. Nergens. Het moeten tabs zijn om de reden hierboven: dan kan iedereen zelf bepalen hoe zijn code wordt weergegeven

• Ga naar de volgende tab-stop (eerste tab-stop: 4, tweede tab-stop: 8, derde tab-stop: 10 (omdat je left white-space wilt beperken bij nested if's) )

Nested if's zijn sowieso een raar fenomeen die je vaak anders moet oplossen. En zelfs daar zijn simpele tabs (die tabs blijven!) altijd voorspelbaar en makkelijk...

• Voeg spaties toe dat het uitlijnt met een character (curly-brace) op een eerdere regel

Nooit spaties voor indentation. Altijd tabs.

Door tabs te verbieden voorkom je ook bij elke non-printable character moet nadenken of het een spatie of een tab is

Huh? Tabs zijn er voor indentation van code. Niets meer, niets minder. Geen spaties.

en dat de code bij iedereen hetzelfde eruit ziet... Tenzij ze proportional font gebruiken zoals comic sans.

En dat wil ik juist voorkomen! Stel je eens voor dat een dev team jou opdraagt: "Vanaf heden gebruiken wij een enkele spatie als indentation, niet 2, geen tabs." Of nog erger: "Wij gebruiken vanaf nu 7 spaties als indentation."

Dan zou jij ook snel denken: "Euh, waarom niet gewoon 1 tab? Dan stel je per IDE maar gewoon in hoe groot jij die wilt weergeven."

Overigens als dit het ergste is wat je bijgebleven is heb je of een super-team of focus je te veel op tabs

Dat is waar. Het toont gewoon aan dat men geen rekening houdt met "developer experience". Spaties zijn gewoon beperkend; tabs geven vrijheid.

[farlane]

.oisyn schreef op maandag 29 augustus 2016 @ 14:03:
[...]
Stel je wilt een leeftijd opslaan. Een leeftijd kan niet negatief zijn, maar tevens heeft het geen "last" van het meer gelimiteerde bereik van positieve getallen van een signed int. Is unsigned int dan toch een betere keuze?

Mijns inziens niet. Het niet negatief kunnen zijn is maar een arbitraire limitatie die toevallig opgaat. De gevolgen van het gebruik van een unsigned int zijn echter een stuk groter. Je kunt leeftijden ineens niet meer van elkaar aftrekken, want dan is het verschil in leeftijd tussen Pietje en Henkie ineens 4 miljard in plaats van -6.

Maar nu geef je een voorbeeld van een leeftijds*verschil* wat niet lekker gaat in een unsigned int.

Dat gezegd hebbende, het gebruik maken van een unsigned type heeft me nu al zo vaak te pakken gehad (met name de promotie naar signed type als er ook een signed type in het spel is ) dat ik het probeer te voorkomen tenzij ik zeker weet dat ik van de unsigned properties ( modulo arithmetic bv ) gebruik kan maken.

[.oisyn]

farlane schreef op maandag 29 augustus 2016 @ 21:38:
[...]

Maar nu geef je een voorbeeld van een leeftijds*verschil* wat niet lekker gaat in een unsigned int.

Maar dat zijn wel de rekenregels die je stilletjes oplegt door dat datatype te gebruiken.

Als het niet mogen opgeven van een negatieve leeftijd een eis is, kun je er beter op checken (zodat het ook faalt) ipv maar gewoon het type unsigned te maken, resulterend in het feit dat daadwerkelijk negatieve leeftijden gewoon geaccepteerd worden door de impliciete conversie naar unsigned.

Unsignedness zorgt gewoon voor heel veel kopzorgen, zoals je zelf ook aangeeft .

[ThomasG]

farlane schreef op maandag 29 augustus 2016 @ 21:38:
[...]

Maar nu geef je een voorbeeld van een leeftijds*verschil* wat niet lekker gaat in een unsigned int.

Dat gezegd hebbende, het gebruik maken van een unsigned type heeft me nu al zo vaak te pakken gehad (met name de promotie naar signed type als er ook een signed type in het spel is ) dat ik het probeer te voorkomen tenzij ik zeker weet dat ik van de unsigned properties ( modulo arithmetic bv ) gebruik kan maken.

When in doubt use int. In principe hoor je enkel een unsigned integer te gebruiken op het moment dat je het nodig daadwerkelijk hebt. Het aan elkaar plakken van twee 16-bit integers naar een 32-bit integer is bijvoorbeeld een geldige reden om unsigned integers te gebruiken. Omdat de waardes toevallig geen negatieve getallen bevatten, niet.

[ard1998]

Voor mijn MBO-4 studie applicatieontwikkelaar staat o.a php 5.3 op het programma (heb hier aardig wat negatiefs over gelezen). Verder html + css + sql + JS

Waarom php 5.3? De stabiele versies zijn al veel verder.

[farlane]

ard1998 schreef op maandag 29 augustus 2016 @ 22:10:
Waarom php 5.3? De stabiele versies zijn al veel verder.

Omdat onderwijs.

[jip_86]

Vermoedelijk omdat ze die cursus al een tijdje recyclen? Je kan het vragen de eerste les, maar soms zul je ook wel eens moeten roeien met een wat ouder stel riemen

[RobIII]

En omdat je moet leren lopen voordat je gaat rennen. En leren lopen kan prima in 5.3, ondanks de gebreken en bugs die in latere versies niet zitten. Welcome to the real world waar lang niet altijd alles "edge" is

[F.West98]

Maar op diezelfde manier kun je dus ook beargumenteren dat de functionaliteit die je nodig hebt voor lopen nauwelijks veranderd is sinds 5.3 (als je 7 buiten beschouwing laat al helemaal) en het dus prima in een nieuwere versie kan, en je onwetende studenten dus ook direct geen slechte gewoonten aanleert (5.3 gebruiken).

[MueR]

RobIII schreef op maandag 29 augustus 2016 @ 23:28:
En omdat je moet leren lopen voordat je gaat rennen. En leren lopen kan prima in 5.3, ondanks de gebreken en bugs die in latere versies niet zitten. Welcome to the real world waar lang niet altijd alles "edge" is

While I agree... 5.3 is dan wel weer een beetje "leer maar eerst vuur maken met twee stokken voordat je een aansteker krijgt". 5.4 is toch wel minimaal wat ik graag zou zien, waar je op z'n minst short array syntax hebt. En ja, dat zeg ik vooral omdat ik tegenwoordig weer moet wennen aan php 5.3 ipv 5.6 en elke keer weer mezelf drie slagen in de rondte vloek op het gebrek aan short arrays.

[RobIII]

F.West98 schreef op maandag 29 augustus 2016 @ 23:38:
Maar op diezelfde manier kun je dus ook beargumenteren dat de functionaliteit die je nodig hebt voor lopen nauwelijks veranderd is sinds 5.3 (als je 7 buiten beschouwing laat al helemaal) en het dus prima in een nieuwere versie kan, en je onwetende studenten dus ook direct geen slechte gewoonten aanleert (5.3 gebruiken).

MueR schreef op dinsdag 30 augustus 2016 @ 00:16:
[...]

While I agree... 5.3 is dan wel weer een beetje "leer maar eerst vuur maken met twee stokken voordat je een aansteker krijgt". 5.4 is toch wel minimaal wat ik graag zou zien, waar je op z'n minst short array syntax hebt. En ja, dat zeg ik vooral omdat ik tegenwoordig weer moet wennen aan php 5.3 ipv 5.6 en elke keer weer mezelf drie slagen in de rondte vloek op het gebrek aan short arrays.

Short arrays is een syntax dingetje. PHP 5.3 heeft conditions, operators, loops, classes, namespaces, what-have-you. Leer eerst maar eens een beetje de basis van programmeren / OOP en daarna kijk je verder. Tuurlijk is 5.4+ beter/leuker/handiger, maar that's not the point

[ Voor 26% gewijzigd door RobIII op 30-08-2016 02:13 ]

[Ryur]

RobIII schreef op dinsdag 30 augustus 2016 @ 02:05:
Short arrays is een syntax dingetje. PHP 5.3 heeft conditions, operators, loops, classes, namespaces, what-have-you. Leer eerst maar eens een beetje de basis van programmeren / OOP en daarna kijk je verder. Tuurlijk is 5.4+ beter/leuker/handiger, maar that's not the point

Sowieso vreemd om als applicatieontwikkelaar PHP 5.3 krijgen.
Ik zou juist als eerste programmeertaal juist Java (om OO aan te leren) aanraden, maar dat is waarschijnlijk het verschil tussen MBO & HBO.

(Note: ik heb weinig/geen ervaring met PHP, laatste was 3 jaar terug; ik weet niet hoe OO nu werkt in PHP, maar de laatste keer was het nog niet helemaal goed werkend.)

[ThomasG]

Ryur schreef op dinsdag 30 augustus 2016 @ 08:08:
[...]

Sowieso vreemd om als applicatieontwikkelaar PHP 5.3 krijgen.
Ik zou juist als eerste programmeertaal juist Java (om OO aan te leren) aanraden, maar dat is waarschijnlijk het verschil tussen MBO & HBO.

(Note: ik heb weinig/geen ervaring met PHP, laatste was 3 jaar terug; ik weet niet hoe OO nu werkt in PHP, maar de laatste keer was het nog niet helemaal goed werkend.)

Daar kun je je lelijk op verkijken. Het is niet zo, omdat Java enkel uit klasse bestaat, dat alles dan maar automatisch OO is. Er zijn genoeg voorbeelden (op scholen) waar het enkel wrappers van functies zijn, en je nog steeds niets OO gerelateerd leert. Java is niet per definitie beter dan PHP. Het gaat er (in het begon) vooral om dat je de logica en het principe begrijpt, en dat kan in PHP een stuk gemakkelijker.

[Ryur]

ThomasG schreef op dinsdag 30 augustus 2016 @ 08:18:
[...]
Daar kun je je lelijk op verkijken. Het is niet zo, omdat Java enkel uit klasse bestaat, dat alles dan maar automatisch OO is. Er zijn genoeg voorbeelden (op scholen) waar het enkel wrappers van functies zijn, en je nog steeds niets OO gerelateerd leert. Java is niet per definitie beter dan PHP. Het gaat er (in het begon) vooral om dat je de logica en het principe begrijpt, en dat kan in PHP een stuk gemakkelijker.

Ik zeg ook niet dat Java automatisch OO is, maar MIJN ervaring is dat het in Java beter OO te schrijven is dan in (mijn verouderde kennis van) PHP.
En ja als je classes gaat gebruiken als wrappers, dan schiet je je doel voorbij.

[ Voor 6% gewijzigd door Ryur op 30-08-2016 08:25 ]

[RayNbow]

Hmm, 4000 strings overpompen van C++-land naar C#-land... 1600ms.

* RayNbow ziet dat de 4000 strings in kwestie keys zijn van een std::map...

Kijken wat er gebeurt als ik de keys ook nog eens apart in een std::vector opsla en die gebruik voor 't overpompen van data...

1ms.

O_O

[DevWouter]

Blue-eagle schreef op maandag 29 augustus 2016 @ 21:14:

[...]

Nee, ik wil gewoon geen spaties. Nergens. Het moeten tabs zijn om de reden hierboven: dan kan iedereen zelf bepalen hoe zijn code wordt weergegeven

Ik bedoelde niet dat het spaties in het document zet, maar dat het de ruimte vult met zoveel spaties.

Maar om een "space-war" (ha!) te voorkomen: Waarom laat je de IDE niet het document reformatten bij openen en opslaan? Sinds ik dat doe zijn tabs vs spaties het laatste waar ik me druk om maak.

[ Voor 8% gewijzigd door DevWouter op 30-08-2016 10:08 ]

[wackmaniac]

DevWouter schreef op dinsdag 30 augustus 2016 @ 10:06:
[...]

Maar om een "space-war" (ha!) te voorkomen: Waarom laat je de IDE niet het document reformatten bij openen en opslaan? Sinds ik dat doe zijn tabs vs spaties het laatste waar ik me druk om maak.

Omdat als ik toevallig hetzelfde doe met tabs mijn diffs continue overhoop liggen met whitespace corrections. Dit is de hele use case voor tabs; jij wilt twee spaties aan ruimte, ik vier. We stellen beide onze IDE/editor zo in en klaar.

[ Voor 12% gewijzigd door wackmaniac op 30-08-2016 10:14 ]

[RayNbow]

Wat we ook kunnen doen is dat we AST's gaan opslaan in plaats van tekst en dat we de diffs op de AST's doen.

De editor vogelt 't maar uit hoe ie de pretty printing moet doen.

[TheNephilim]

Hmmm, heb eigenlijk altijd gewoon 4 spaties in gebruik. Vroeger, toen ik nog op school zat, waren tabs evil. Maar als ik de argumenten hier zo lees, dan is het inderdaad wel logisch, tabs voor indentation.

[DevWouter]

wackmaniac schreef op dinsdag 30 augustus 2016 @ 10:12:
[...]


Omdat als ik toevallig hetzelfde doe met tabs mijn diffs continue overhoop liggen met whitespace corrections. Dit is de hele use case voor tabs; jij wilt twee spaties aan ruimte, ik vier. We stellen beide onze IDE/editor zo in en klaar.

Daar heb ik nooit aan gedacht. Echter de meeste diff-tools kunnen whitespace negeren. Bovendien kan de ene één tab aanhouden terwijl de andere weer twee gebruikt (waarom? Bijvoorbeeld omdat het beter uitlijnt).

Persoonlijk wil ik maximaal twee whitespace characters in mijn document hebben: Verticale whitespace en horizontale whitespace.

Verticaal mag LF, CR of CR+LF zijn.
Horizontaal mag Spatie of tab zijn.

Echter binnen het document wil ik er maar één van elk hebben.

Heb trouwens voor de gein een stuk code gepakt en alle spaties vervangen door een tab en alleen commentaar ziet er vreemd uit. Volgens mij heb ik iets nieuws ontdekt.

RayNbow schreef op dinsdag 30 augustus 2016 @ 10:16:
Wat we ook kunnen doen is dat we AST's gaan opslaan in plaats van tekst en dat we de diffs op de AST's doen.

Ja... Een diff van een AST zijn leuk om te lezen.

[incaz]

DevWouter schreef op dinsdag 30 augustus 2016 @ 10:49:
Daar heb ik nooit aan gedacht. Echter de meeste diff-tools kunnen whitespace negeren. Bovendien kan de ene één tab aanhouden terwijl de andere weer twee gebruikt (waarom? Bijvoorbeeld omdat het beter uitlijnt).

Nou heb ik zelf het idee dat ik best een open mind heb in de tabs-vs-spaces-discussie (als in: hou je aan de standaarden die zijn afgesproken, en laat het verder door de editor regelen), maar hoe in de wereld gaat iemand 2 tabs gebruiken op een plek waar er 1 hoort?

[Devilly]

incaz schreef op dinsdag 30 augustus 2016 @ 11:17:
[...]


Nou heb ik zelf het idee dat ik best een open mind heb in de tabs-vs-spaces-discussie (als in: hou je aan de standaarden die zijn afgesproken, en laat het verder door de editor regelen), maar hoe in de wereld gaat iemand 2 tabs gebruiken op een plek waar er 1 hoort?

Je moet gewoon twee keer op de tab knop drukken.

[Rutix]

Devilly schreef op dinsdag 30 augustus 2016 @ 11:31:
[...]


Je moet gewoon twee keer op de tab knop drukken.

Maar dat is gewoon een pannekoek dan. Want dan zou hij ook 4 spaces gebruiken ipv 2 spaces.

[Jegorex]

Rutix schreef op dinsdag 30 augustus 2016 @ 11:34:
[...]

Maar dat is gewoon een pannekoek dan. Want dan zou hij ook 4 spaces gebruiken ipv 2 spaces.

Laten we een tab 1 space maken en 4x op de tab rammen

[TheNephilim]

Leesbaarder dan normale regex, dat wel: https://simple-regex.com/

[RayNbow]

DevWouter schreef op dinsdag 30 augustus 2016 @ 10:49:


[...]


Ja... Een diff van een AST zijn leuk om te lezen.

Is vast wel ook te prettyprinten.

[Devilly]

TheNephilim schreef op dinsdag 30 augustus 2016 @ 11:37:
Leesbaarder dan normale regex, dat wel: https://simple-regex.com/

Kijkend naar het voorbeeld vind ik de normale regex fijner.

[Woy]

TheNephilim schreef op dinsdag 30 augustus 2016 @ 11:37:
Leesbaarder dan normale regex, dat wel: https://simple-regex.com/

Ik vind het eigenlijk helemaal niet leesbaarder. De leesbaarheid komt puur door de syntax highlighting, en dat kan met regex natuurlijk ook prima.

[DevWouter]

incaz schreef op dinsdag 30 augustus 2016 @ 11:17:
[...]


Nou heb ik zelf het idee dat ik best een open mind heb in de tabs-vs-spaces-discussie (als in: hou je aan de standaarden die zijn afgesproken, en laat het verder door de editor regelen), maar hoe in de wereld gaat iemand 2 tabs gebruiken op een plek waar er 1 hoort?

Naar mijn idee is ook nog niemand op de baricade gesprongen. Ongeacht of je voor spaties of tabs kiest, je ziet er toch niks van

Twee tabs is bijvoorbeeld als je functie argumenten over meerdere regels uitsmeert en je wilt uitlijnen

C++:

// When your tab is the size of 4
void fn(int a, // the "i" of int is the 9th character
        int b); // the "i" of int is the 3th character (tab, tab, "i")

// When your tab is the size of 8
void fn(int a, // the "i" of int is the 9th character
                int b); // the "i" of int is the 3th character (tab, tab, "i")

// When your tab is the size of 2
void fn(int a, // the "i" of int is the 9th character
    int b); // the "i" of int is the 3th character (tab, tab, "i")

Volgens mij is de perfecte oplossing helemaal geen spaties of tabs gebruiken. Maar schrijven we dan alles in CamelCase or in snake_case?

[TheNephilim]

Ik ben geen regex expert, wellicht vind ik het daardoor beter leesbaar. Er staat immers letterlijk wat het moet doen, voor normale regex moet ik toch echt even goed nadenken hoor

Maar inderdaad, het schrijven is geen doen op die manier, dan is normale regex toch net even makkelijker. Ik pak meestal https://regex101.com/ om regex te schrijven; gemakkelijk debuggen ed.

[incaz]

DevWouter schreef op dinsdag 30 augustus 2016 @ 12:22:

Twee tabs is bijvoorbeeld als je functie argumenten over meerdere regels uitsmeert en je wilt uitlijnen
[knip]

Prima voorbeeld waarom dat echt helemaal niet werkt

Zo had de status quo nu moeten zijn:
http://nickgravgaard.com/elastic-tabstops/

[.oisyn]

DevWouter schreef op dinsdag 30 augustus 2016 @ 12:22:
Twee tabs is bijvoorbeeld als je functie argumenten over meerdere regels uitsmeert en je wilt uitlijnen

Dan gebruik je tabs verkeerd. Tabs zijn voor indenting. Spaties zijn voor uitlijning. Je begint de regel die je wilt uitlijnen dus met net zoveel tabs als de regel erboven. Daarna voeg je spaties toe.

Resultaat: altijd goed uitgelijnd, en iedereen kan zijn eigen favoriete tabgrootte gebruiken.

[DevWouter]

.oisyn schreef op dinsdag 30 augustus 2016 @ 13:07:
[...]

Dan gebruik je tabs verkeerd. Tabs zijn voor indenting. Spaties zijn voor uitlijning. Je begint de regel die je wilt uitlijnen dus met net zoveel tabs als de regel erboven. Daarna voeg je spaties toe.

Resultaat: altijd goed uitgelijnd, en iedereen kan zijn eigen favoriete tabgrootte gebruiken.

Zeg ook niet dat het goed was, maar een handigere regel vind ik om jezelf aan te leren dat je IDE geen excel is. Om het moment dat je code gaat uitlijnen is er iets anders mis met je code

incaz schreef op dinsdag 30 augustus 2016 @ 12:33:
[...]


Prima voorbeeld waarom dat echt helemaal niet werkt

Zo had de status quo nu moeten zijn:
http://nickgravgaard.com/elastic-tabstops/

Oh nice, was nog niet bekend met deze variant. Misschien dadelijk even proberen.

[EddoH]

Ryur schreef op dinsdag 30 augustus 2016 @ 08:24:
[...]

En ja als je classes gaat gebruiken als wrappers, dan schiet je je doel voorbij.

Ik gebruik eigenlijk best vaak classes als een wrapper om een collectie functies die 'iets' specifieks doet. Als je een abstractie om elke functionaliteit gaat maken ben je ook niet heel lekker bezig. Wel enterprisey. Dat wel.

Vooral hoe dichter je naar specifieke user interface functionaliteiten of acties werkt, hoe meer ik de abstracties/pure OO loslaat.

[ThomasG]

EddoH schreef op dinsdag 30 augustus 2016 @ 13:34:
[...]


Ik gebruik eigenlijk best vaak classes als een wrapper om een collectie functies die 'iets' specifieks doet. Als je een abstractie om elke functionaliteit gaat maken ben je ook niet heel lekker bezig. Wel enterprisey. Dat wel.

Vooral hoe dichter je naar specifieke user interface functionaliteiten of acties werkt, hoe meer ik de abstracties/pure OO loslaat.

Daarom zijn talen als C++ ook zo mooi. Je kunt ook gewoon functies gebruiken, en dat maakt het niet ineens minder OO. Ik geloof dat zoiets nu ook in java kan met static imports, maar dan moet je het nog altijd in een util klasse zetten.

[RagingPenguin]

ThomasG schreef op dinsdag 30 augustus 2016 @ 13:36:
[...]
Daarom zijn talen als C++ ook zo mooi. Je kunt ook gewoon functies gebruiken, en dat maakt het niet ineens minder OO. Ik geloof dat zoiets nu ook in java kan met static imports, maar dan moet je het nog altijd in een util klasse zetten.

Iets wat in PHP ook perfect kan

[bwerg]

ThomasG schreef op dinsdag 30 augustus 2016 @ 13:36:
[...]
Ik geloof dat zoiets nu ook in java kan

Dit impliceert dat static methods er niet al sinds java 1.0 in zaten?

De main-method is de eerste functie die iedereen leert, dat is gewoon een niet-OO functie.

[EddoH]

RagingPenguin schreef op dinsdag 30 augustus 2016 @ 13:48:
[...]


Iets wat in PHP ook perfect kan

PHP is gewoon ruk. Period.

[kwaakvaak_v2]

ooh... een talen oorlog, dat is toch al zeker 2 pagina's terug...

[Merethil]

kwaakvaak_v2 schreef op dinsdag 30 augustus 2016 @ 15:07:
ooh... een talen oorlog, dat is toch al zeker 2 pagina's terug...

"Oorlog". Er is toch al "Period" gezegd? Dan is het helemaal over, je weet.

[F.West98]

C# > Java > PHP => C# >> PHP
C# is dus superieur, dûh
Period.

[ Voor 7% gewijzigd door F.West98 op 30-08-2016 15:30 ]

[Merethil]

F.West98 schreef op dinsdag 30 augustus 2016 @ 15:30:
C# < Java > PHP => C# >> PHP
C# is dus niet superieur, dûh
Period.

FTFY

[F.West98]

Merethil schreef op dinsdag 30 augustus 2016 @ 15:31:
[...]


FTFY

2 < 10 > 5 => 2 >> 5
Wat is dat nou voor logica?

[Merethil]

F.West98 schreef op dinsdag 30 augustus 2016 @ 15:37:
[...]

2 < 10 > 5 => 2 >> 5
Wat is dat nou voor logica?

Nou gewoon, 2 is kleiner dan 10 maar groter dan 5. Dus 2 zit ergens tussen 5 en 10 in. Duh.

[incaz]

Merethil schreef op dinsdag 30 augustus 2016 @ 15:18:
[...]


"Oorlog". Er is toch al "Period" gezegd? Dan is het helemaal over, je weet.

Maar, maar, niet alleen php maar ongeveer elke moderne taal sluit toch af met semicolons?

[EddoH]

kwaakvaak_v2 schreef op dinsdag 30 augustus 2016 @ 15:07:
ooh... een talen oorlog, dat is toch al zeker 2 pagina's terug...

Oh ja? Is dat onderwerp al eerder voorgekomen? Verdorie.

[Merethil]

incaz schreef op dinsdag 30 augustus 2016 @ 15:41:
[...]


Maar, maar, niet alleen php maar ongeveer elke moderne taal sluit toch af met semicolons?

Behalve de Nederlandse taal. En de Engelse taal. En de Franse taal. En nog een hele hoop meer. Eigenlijk sluit slechts een heel klein deel van de talen op deze wereld af met semicolons

[incaz]

Merethil schreef op dinsdag 30 augustus 2016 @ 15:42:
[...]

Behalve de Nederlandse taal. En de Engelse taal. En de Franse taal. En nog een hele hoop meer. Eigenlijk sluit slechts een heel klein deel van de talen op deze wereld af met semicolons

Maar dat zijn impure talen. Die tellen niet. Punten dienen om membervars aan te duiden of in enkele verguisde situaties om strings juist aan elkaar te plakken, niet om statements te eindigen!

(Nu ik dat zo opschrijf: waarom is er eigenlijk gekozen om niet de punt te gebruiken voor einde statements? Waarom de puntkomma? Hoe is dat zo ontstaan?)

[Merethil]

incaz schreef op dinsdag 30 augustus 2016 @ 15:49:
[...]


Maar dat zijn impure talen. Die tellen niet. Punten dienen om membervars aan te duiden of in enkele verguisde situaties om strings juist aan elkaar te plakken, niet om statements te eindigen!

(Nu ik dat zo opschrijf: waarom is er eigenlijk gekozen om niet de punt te gebruiken voor einde statements? Waarom de puntkomma? Hoe is dat zo ontstaan?)

Vroeger, toen toetsenborden nog kleiner waren en alle ruimte belangrijk was om te gebruiken hebben we de komma en punt maar samengevoegd. Niemand had een punt, of een komma. Alleen een puntkomma. Toen de eerste programmeertalen kwamen moest je dus elke zin eindigen met een puntkomma omdat je gewoon niets anders had.

---

Disclaimer: Bovenstaande is totale onzin. Ik ben 25, de eerste programmeertaal ooit is toch van iets vóór mijn tijd.

[F.West98]

Merethil schreef op dinsdag 30 augustus 2016 @ 15:53:
[...]


Vroeger, toen toetsenborden nog kleiner waren en alle ruimte belangrijk was om te gebruiken hebben we de komma en punt maar samengevoegd. Niemand had een punt, of een komma. Alleen een puntkomma. Toen de eerste programmeertalen kwamen moest je dus elke zin eindigen met een puntkomma omdat je gewoon niets anders had.

---

Disclaimer: Bovenstaande is totale onzin. Ik ben 25, de eerste programmeertaal ooit is toch van iets vóór mijn tijd.

[dcm360]

Komma's worden gebruikt om argumenten te scheiden, punten voor kommagetallen, en puntkomma's dus maar om statements mee te scheiden. Hergebruiken had ook gekund, maar dan wordt de compiler ingewikkelder.

Overigens kan ik Scala, Javascript en Python noemen als talen waarbij de puntkomma niet verplicht is.

[Mercatres]

Het rondt ook mooier af.

[Merethil]

Mercatres schreef op dinsdag 30 augustus 2016 @ 16:13:
Het rondt ook mooier af;

FTFY;

[incaz]

dcm360 schreef op dinsdag 30 augustus 2016 @ 16:03:
Komma's worden gebruikt om argumenten te scheiden, punten voor kommagetallen

Ah, de getallen, die was ik helemaal vergeten! Dan is het inderdaad heel logisch - kan ik toch nog rustig slapen vannacht

[bwerg]

incaz schreef op dinsdag 30 augustus 2016 @ 15:49:
[...]


Maar dat zijn impure talen. Die tellen niet. Punten dienen om membervars aan te duiden of in enkele verguisde situaties om strings juist aan elkaar te plakken, niet om statements te eindigen!

Inderdaad, pure talen als Haskell hebben... Oh ja, die hebben eigenlijk nooit puntkomma's.

[F.West98]

Dat zijn half pure talen In gewone taal kan je ook prima zonder punten, maar daar word je niet heel blij van zoals je kan zien Dit illustreert dat dus wel goed Dus Denk ik

[bwerg]

Haskell half-puur? Laat het de wiskundigen maar niet horen.

[RayNbow]

incaz schreef op dinsdag 30 augustus 2016 @ 15:49:
[...]

(Nu ik dat zo opschrijf: waarom is er eigenlijk gekozen om niet de punt te gebruiken voor einde statements? Waarom de puntkomma? Hoe is dat zo ontstaan?)

Waarom een puntkomma om het einde aan te geven? Waarom niet een puntkomma om statements te scheiden zoals in ALGOL en Pascal?

[RagingPenguin]

EddoH schreef op dinsdag 30 augustus 2016 @ 14:03:
PHP is gewoon ruk. Period.

Misschien moet je ff terug lezen waar het eigenlijk over ging

RayNbow schreef op dinsdag 30 augustus 2016 @ 17:33:
[...]

Waarom een puntkomma om het einde aan te geven? Waarom niet een puntkomma om statements te scheiden zoals in ALGOL en Pascal?

Dat is toch wat er in de meeste talen gebeurd? In een for koop heb je meerdere statements, gescheiden door een ;. (Of snap ik niet helemaal wat je bedoelt?)

[ Voor 19% gewijzigd door RagingPenguin op 30-08-2016 17:48 ]

[RayNbow]

RagingPenguin schreef op dinsdag 30 augustus 2016 @ 17:45:
[...]


Dat is toch wat er in de meeste talen gebeurd? In een for koop heb je meerdere statements, gescheiden door een ;. (Of snap ik niet helemaal wat je bedoelt?)

In een taal als C dien je elk statement af te sluiten met een puntkomma. Dat is niet het geval in bijv. Pascal. Zie de volgende twee codevoorbeelden:

Delphi:

program Hello;
begin
  writeln ('Hello');
  writeln ('world.')
end.

C:

int main() {
    printf("Hello\n");
    printf("world.\n");
    return 0  // syntax error als ik hier geen puntkomma plaats
}

[incaz]

Maar, wordt het daar nou beter van, van zo'n niet afgesloten statement aan het einde?

[bwerg]

Ik vindt het juist wel fijn dat je in (bijvoorbeeld) in arrays in Java wél komma's als separator kan zetten als dat niet per se hoeft.

Java:

new [String]{
    "aap",
    "noot",
    "mies",
};

Comment een entry uit of voeg er een toe, zonder dat je nog de komma's op voorgaande regels moet fixen.

Separators zijn maar moeilijk. Altijd leuk als je even ad-hoc een parsertje/regex in elkaar knalt: een separator is altijd moeilijker dan "na elke statement komt een puntkomma".

[RayNbow]

incaz schreef op dinsdag 30 augustus 2016 @ 18:50:
Maar, wordt het daar nou beter van, van zo'n niet afgesloten statement aan het einde?

In Pascal sluit je geen statements af, je scheidt ze, dus het begrip "niet afgesloten statement" heeft weinig betekenis.

Je kunt trouwens in het geval van Pascal er wel een puntkomma plaatsen achter het laatste statement. Dan bestaat het block namelijk uit 3 statements (2 writelns en 1 leeg statement).

bwerg schreef op dinsdag 30 augustus 2016 @ 19:03:
Ik vindt het juist wel fijn dat je in (bijvoorbeeld) in Java wél komma's als separator kan zetten als dat niet per se hoeft.

Java:

new [String]{
    "aap",
    "noot",
    "mies",
};

Comment een entry uit of voeg er een toe, zonder dat je nog de komma's op voorgaande regels moet fixen.

Separators zijn maar moeilijk. Altijd leuk als je even ad-hoc een parsertje in elkaar knalt: een separator is altijd moeilijker dan "na elke statement komt een puntkomma".

Maar waarom is het daar optioneel om een komma te plaatsen en ben je verplicht elk statement te voorzien van een puntkomma? Waarom mag je daarentegen bijv. geen extra komma plaatsen in een argumentenlijst plaatsen?

Het is allemaal zo inconsistent.

[bwerg]

Schrijf ze maar op in het lijstje van slechte ontwerpkeuzes van Java. Maar die extra komma is wel leuk.

[ Voor 19% gewijzigd door bwerg op 30-08-2016 19:31 ]

[incaz]

RayNbow schreef op dinsdag 30 augustus 2016 @ 19:07:
[...]

In Pascal sluit je geen statements af, je scheidt ze, dus het begrip "niet afgesloten statement" heeft weinig betekenis.

Wat erg leuk is voor de parser-lexer maar waarom zou ik dat interessant vinden?

Is het voor de programmeur beter? Maakt het de code beter te onderhouden, beter leesbaar? Ik ben zelf geneigd te zeggen van niet.

En ik zet dan ook braaf semicolons aan het einde van mijn javascriptstatements, en loop er af en toe tegenaan dat je in json geen komma aan het einde mag, omdat je daar inderdaad dingen aan het scheiden bent, niet aan het afsluiten...

[.oisyn]

bwerg schreef op dinsdag 30 augustus 2016 @ 19:09:
Schrijf ze maar op in het lijstje van slechte ontwerpkeuzes van Java. Maar die extra komma is wel leuk.

Dat hebben ze van C geleend overigens.

[bwerg]

.oisyn schreef op dinsdag 30 augustus 2016 @ 20:14:
[...]

Dat hebben ze van C geleend overigens.

Zet ook maar op dat lijstje, dan.

[Skyaero]

Ik krijg een punthoofd van al dit kommaneuken.

[.oisyn]

De reden om dat toe te staan is voor gegenereerde code en het makkelijk uit kunnen commenten of herordenen van regels.

Dat Pascal de ; gebruikt als separator en het dus niet verplicht is voor de laatste statement resulteert in editing hell.

[ Voor 34% gewijzigd door .oisyn op 30-08-2016 21:23 ]