De Devschuur Coffee Corner - Iteratie ➓

[farlane]

DevWouter schreef op donderdag 22 september 2016 @ 11:42:
[...]
Bullcrap, C11 heeft support voor atomic operations en daar was 40 jaar niet veel vraag naar en nu wel.

Het weglaten van array bounds checking is niet nieuw in C11, dat zit er al iets langer in.

Als je dat wel wilt staat het je vrij om dat in je user code wel te doen, dat is de 'spirit' van C.

Firesphere schreef op donderdag 22 september 2016 @ 11:51:
Ik vind het redelijk een "nobel doel" om er voor te zorgen dat mensen zich niet minderwaardig voelen, of depressief worden, door een attitude die zeer sterk aanwezig is in de sociale omgeving, en zich in de technologie industrie ook nog eens extra uit.

Prima, ik zal je niet tegenhouden Ik denk overigens niet dat het in de technologie industrie extra aanwezig is, het is overal aanwezig : zelfs in het bejaardentehuis is er dit soort groepsgedrag. Voor mij is het volstrekt logisch dat het bestaat, dit is iets wat in onze genen is ingebouwd.

[CodeCaster]

Firesphere schreef op donderdag 22 september 2016 @ 11:55:
[...]

Of constructieve feedback, geef aan wat er mis is en waarom in plaats van zeggen "Dat is kut"?
Je hoeft die wordpress theme niet te gebruiken, maar je kan wel uitleggen hoe het beter kan en dat je daarom het niet zal gebruiken.

[...]

Nee, je hoeft niet altijd positief te zijn. Maar dat is iets anders dan denigrerend zijn. Je kan gewoon zeggen dat iets kut is ofzo, vind ik best.
Maar vertel er wel bij waarom?

Omdat iedereen het zegt, is geen argument.

Jantje: Kijk eens wat een mooie website ik heb gemaakt met PHP!
Pietje: PHP Ga toch een echte taal gebruiken.

Als het niet overduidelijk is dat Pietje hier een triest persoon is, weet ik het ook niet meer. Als Jantje daarvan echter onzeker wordt en zijn toetsenbord aan de wilgen hangt, is dát Jantjes probleem.

[RayNbow]

bwerg schreef op donderdag 22 september 2016 @ 11:22:
[...]

Heb ik het retorische karakter van je vraag gemist of verbaast het antwoord

Java:

<T extends Food> int countFreshFood (List<T> foods) { /* bla */}

je? Oh, zie enkele posts later voor een natuurlijk nog beter antwoord...

Het was een oefening-voor-de-lezer.

Merethil schreef op donderdag 22 september 2016 @ 11:31:
[...]


Even geprobeerd, kwam hier op uit:

Java:

private int countFreshFood(List<? extends Food> list) {
    int freshFoodCount = 0;
    for (Food food : list) {
        if (food.fresh()) {
            freshFoodCount ++;
        }
    }
    return freshFoodCount;
}

Kan nu een List van Banana, Apple of Food erin gooien, die geven allemaal prima een count terug.
Een List van String, Integer of wat dan ook levert echter een error op.

Ja, maar wel een compile error (zoals het hoort).

Het zou mooi zijn geweest als arrays in Java en C# net als generics standaard invariant waren en dat functies optioneel aan konden geven of ze een array co- of contravariant willen gebruiken.

Extra oefening: Schrijf ProcessFoodProducts die een of andere generic class gebruikt i.p.v. arrays.

[DevWouter]

.oisyn schreef op donderdag 22 september 2016 @ 11:46:
[...]

Dat maakt de opmerking van farlane toch geen "bullcrap"

Ik vind de bewering dat 'C bedacht is voor platformen van +/-40 jaar' geleden onzin gezien we C11 hebben. C11 is waarschijnlijk bedoeld voor meer recente systemen.

Bovendien is C89 maar 27 jaar oud

Misschien Waarschijnlijk dat ik het iets beter had kunnen opschrijven.

farlane schreef op donderdag 22 september 2016 @ 11:58:
[...]

Het weglaten van array bounds checking is niet nieuw in C11, dat zit er al iets langer in.

Sorry, zoals ik aangaf was ik niet duidelijk. Het is de combinatie "C" en "40 jaar" waar ik over viel. Over de verdere inhoudelijk discussie heb ik geen mening.

[ThomasG]

RayNbow schreef op donderdag 22 september 2016 @ 11:59:
[...]

Het was een oefening-voor-de-lezer.


[...]

Ja, maar wel een compile error (zoals het hoort).

Het zou mooi zijn geweest als arrays in Java en C# net als generics standaard invariant waren en dat functies optioneel aan konden geven of ze een array co- of contravariant willen gebruiken.

Het probleem is dat Java helemaal geen generics heeft. Ja, "nep" generics. Want het is een compiler truc waarbij het wordt omgezet naar casts. Wanneer je Java compileert is er totaal geen verschil tussen een List<A> en List<B>. Enkel C# heeft de generics op bytecode niveau. (C++ templates zijn trouwens ook geen generics).

[Merethil]

ThomasG schreef op donderdag 22 september 2016 @ 12:02:
[...]
Het probleem is dat Java helemaal geen generics heeft. Ja, "nep" generics. Want het is een compiler truc waarbij het wordt omgezet naar casts. Wanneer je Java compileert is er totaal geen verschil tussen een List<A> en List<B>. Enkel C# heeft de generics op bytecode niveau. (C++ templates zijn trouwens ook geen generics).

Maar is dat dan een probleem? Het is toch opgelost in de taal en dus kan je het gebruiken alszijnde generics?

[farlane]

DevWouter schreef op donderdag 22 september 2016 @ 12:02:
[...]
Ik vind de bewering dat 'C bedacht is voor platformen van +/-40 jaar' geleden onzin gezien we C11 hebben. C11 is waarschijnlijk bedoeld voor meer recente systemen.

De gedachte is nog altijd dat er zo weinig mogelijk aannames worden gedaan op welk platform de binary terecht komt en dat je zo weinig mogelijk aannames doet over wat dat platform wel en niet kan.

[ThomasG]

Merethil schreef op donderdag 22 september 2016 @ 12:04:
[...]


Maar is dat dan een probleem? Het is toch opgelost in de taal en dus kan je het gebruiken alszijnde generics?

Nee, want Java weet runtime het verschil niet. Een code als:

Java:

public void Foo(List<Bar> bar);
public void Foo(List<Baz> baz);

Kan niet in Java. Als je het type wilt achterhalen van de generic, zal je dat in Java heel omslachtig moeten doen, omdat Java het zelf niet weet. Bij C# kan dat allemaal wel.

[gekkie]

Klittenband

[Firesphere]

CodeCaster schreef op donderdag 22 september 2016 @ 11:58:
[...]


[...]

Als het niet overduidelijk is dat Pietje hier een triest persoon is, weet ik het ook niet meer. Als Jantje daarvan echter onzeker wordt en zijn toetsenbord aan de wilgen hangt, is dát Jantjes probleem.

Nou nee, niet echt.
Omdat niet alleen Pietje het zegt, maar zo ongeveer 90% hier dat doet. dat is wat ik aanduid.

[.oisyn]

ThomasG schreef op donderdag 22 september 2016 @ 12:02:
[...]
Het probleem is dat Java helemaal geen generics heeft.

Dat is helemaal geen "probleem" voor de feauture die RayNbow aandraagt?

DevWouter schreef op donderdag 22 september 2016 @ 12:02:
[...]


Ik vind de bewering dat 'C bedacht is voor platformen van +/-40 jaar' geleden onzin gezien we C11 hebben. C11 is waarschijnlijk bedoeld voor meer recente systemen.

Dat is een redenatiefout - het een sluit het andere niet uit namelijk. C11 heeft nog steeds de bagage van 40 jaar geleden.

[ Voor 45% gewijzigd door .oisyn op 22-09-2016 12:18 ]

[ThomasG]

.oisyn schreef op donderdag 22 september 2016 @ 12:16:
[...]

Dat is helemaal geen "probleem" voor de feauture die RayNbow aandraagt?

Niet direct. Maar Java heeft een hardnekkige type erasure (voor backwards compatibility..), waardoor zo'n feature in Java vrijwel onmogelijk is tenzij ze de hele compiler op de schop nemen.

[CodeCaster]

Firesphere schreef op donderdag 22 september 2016 @ 12:11:
[...]

Nou nee, niet echt.
Omdat niet alleen Pietje het zegt, maar zo ongeveer 90% hier dat doet. dat is wat ik aanduid.

Terugkomend op mijn vorige post: mensen moeten bevestiging zoeken bij hun peers, of bij mensen die gebaat zijn bij hun verbetering.

Ik kan aan mijn familie ook trots een lap code laten zien, en dan krijg ik als antwoord "Dus je hebt lekker knopjes ingedrukt in je vrije tijd? In die tijd had je ook eindelijk eens je radiatoren kunnen schilderen".

Ja, misschien is de "Haha, PHP "-circlejerk in dit topic te groot. Voor zover ik het echter doorheb, bedoelt men het gewoon grappig, en heeft men tegelijkertijd niet door dat de grap er allang af is.

Overigens is de enige relevante reactie die ik zo snel kan vinden die slaat op jouw relaas deze: kenneth in "De Devschuur Coffee Corner - Iteratie ➓", en kenneth een béétje kennende, bedoelde 'ie dat meer als "Oh nee, niet weer die tot in den treure herkauwde PHP-discussie".

[gekkie]

ThomasG schreef op donderdag 22 september 2016 @ 11:54:
[...]
http://www.dumpert.nl/med...f/rob_snapt_het_niet.html

Helder voorbeeld, je ziet de jongens in volle vertwijfeling blijven staan .

[Merethil]

ThomasG schreef op donderdag 22 september 2016 @ 12:07:
[...]
Nee, want Java weet runtime het verschil niet. Een code als:

Java:

public void Foo(List<Bar> bar);
public void Foo(List<Baz> baz);

Kan niet in Java. Als je het type wilt achterhalen van de generic, zal je dat in Java heel omslachtig moeten doen, omdat Java het zelf niet weet. Bij C# kan dat allemaal wel.

Klopt, maar heb je daar een use-case voor die niet FooBarBaz is? Want ook hierbij zie ik het probleem weer niet zo.

[ThomasG]

Merethil schreef op donderdag 22 september 2016 @ 12:46:
[...]


Klopt, maar heb je daar een use-case voor die niet FooBarBaz is? Want ook hierbij zie ik het probleem weer niet zo.

Zoals ik eerder al had aangegeven doet Java aan hardnekkige type erasure. Je krijgt in Java van sowieso een halfbakken oplossing, omdat je dan nog steeds kunt doen wat je niet wilt.

[Merethil]

ThomasG schreef op donderdag 22 september 2016 @ 12:54:
[...]
Zoals ik eerder al had aangegeven doet Java aan hardnekkige type erasure. Je krijgt in Java van sowieso een halfbakken oplossing, omdat je dan nog steeds kunt doen wat je niet wilt.

Nee, ik vraag om een voorbeeld waarom je het wilt doen, en wat je doel ermee is.
Want waarom niet gewoon

Java:

public void FooBars(List<Bar> bar);
public void FooBazs(List<Baz> baz);

Het is duidelijker naar de gebruiker/developer na je/de rest van de wereld, en ik heb persoonlijk nog nooit een use-case gezien waarin je zowel Foo() wilt aanroepen voor een lijst van Bar, als Foo voor een lijst van Baz zonder dat Bar en Baz een relatie hebben in de vorm van het implementeren van een interface (waardoor je mijn eerdere voorbeeld zou gebruiken in Java).

Wat is het praktisch nut volgens jou?

[kenneth]

CodeCaster schreef op donderdag 22 september 2016 @ 12:23:
Overigens is de enige relevante reactie die ik zo snel kan vinden die slaat op jouw relaas deze: kenneth in "De Devschuur Coffee Corner - Iteratie ➓", en kenneth een béétje kennende, bedoelde 'ie dat meer als "Oh nee, niet weer die tot in den treure herkauwde PHP-discussie".

Dus dat.

Taaldiscussies zijn heel interessant en leerzaam (zeker als RayNbow meedoet) zolang ze zich afspelen in het spectrum beter-slechter en niet het absolute good vs evil. Bijna elke taal heeft mindere kanten (zelfs voor het beoogde doel) of zelfs fuck-ups en het is heel nuttig om te weten wat die zijn en waarom het fuck-ups zijn. Veel taalarchitecten zelf hebben achteraf berouw over bepaalde keuzes. Volgens mij legt Eric Lippert nog steeds elke paar maanden uit waarom hij spijt heeft van array covariance in C#.

En verder is de beste taal natuurlijk Haskell; het is immers zo goed dat niemand het gebruikt

[incaz]

CodeCaster schreef op donderdag 22 september 2016 @ 11:42:
[...]

Misschien omdat geveinsd respect schijnheiliger is dan direct zijn.

False dichotomy.

Het is intrigerend hoe vaak die neptegenstelling voorkomt. Alsof er echt maar 2 mogelijkheden zijn: schijnheilig zijn, of 'direct' als oplossing voor hoe bot je maar wilt zijn die dag.

Maar, er zijn dus meer opties.
1. je kunt oprecht het goede in iets of iemand zien zonder schijnheilig te zijn. Daarvoor kies je dan wellicht een andere meetlat en geef je feedback op inspanning en niet alleen op resultaat: je hoeft de kindertekening van een 4-jarige niet te gaan evalueren op doordacht kleurgebruik of correct perspectief en het toch gewoon heel leuk vinden. Leuk omdat je wordt meegenomen in iets wat je zelf misschien alweer vergeten was. Niets schijnheiligs aan. Als ik mensen aanmoedig of feedback geef, is dat altijd oprecht. Maar ik vind het dan ook oprecht leuk om ontwikkeling van heel veel mensen te zien.

2. Je kunt vragen of de ander behoefte heeft aan feedback, en dat antwoord kan nee zijn. In dat geval hoef je helemaal niets te doen, en nadrukkelijk niet je mening te geven. Of je hebt het over iets totaal anders, of je vraagt bv dingen zonder daarin je mening te geven (lukte het een beetje, heb je bereikt wat je wilde, kwam je rare dingen tegen, vond je het leuk, etc.)

3. Je kunt je feedback geven zonder negatief / bot denigrerend te zijn. Het is prima mogelijk om constructieve kritiek te geven die wel inhoudelijk is maar niemands eigenwaarde aantast. Dat kan soms in de vorm van vragen (was het een bewuste keuze om), soms door het heel erg specifiek te houden op wat er gebeurt (in regel 59 kan de expressie false opleveren als [uitzonder], wellicht is dat niet wat je wilt), of je kunt je eigen ervaring delen, niet 'welke idioot gebruikt er [x]' maar 'bij gebruik van [x] kwam ik probleem [y] tegen, dat is iets om in de gaten te houden'

Als mensen iets beneden hun niveau of gewoon niet interessant vinden, dan mogen ze dat gewoon zeggen.

Het mag, als in 'het is niet verboden.' Maar het nut ervan ontgaat me. De gevolgen van al dat 'ik moet dat gewoon kunnen zeggen' is vrijwel nooit iets constructiefs, dus waarom zou je andermans tijd en energie verspillen alleen omdat je zo nodig iets moet uiten terwijl je niet de interesse hebt om dat te doen op een zinnige manier? (Wil je code kwaliteit of programmeurskwaliteit verbeteren, dan begint dat met betere vormen van feedback, waarin niet het recht om alles te kunnen zeggen voorop staat, maar het nut van wat je wilt zeggen. Als je dat niet op kunt brengen, waarom dan niet gewoon die verzendknop overslaan? Typ het, uit het, ctrl-A->del en niemand heeft er last van.)

Of, laat ik de vraag omdraaien: mag je negativiteit niet uiten? Moet alles altijd maar positief zijn?

Ook dat is een false dichotomy, alsof er niet meer dan 2 opties zijn ipv een glijdende schaal. Ik zou zeggen dat we een heel stuk op kunnen schuiven en dan nog steeds niet in een situatie zijn waar 'alles altijd' positief moet zijn.

[bwerg]

kenneth schreef op donderdag 22 september 2016 @ 13:05:
En verder is de beste taal natuurlijk Haskell; het is immers zo goed dat niemand het gebruikt

Waarvan ik me nog regelmatig aan ontwerpkeuzes stoor. En de community ook, aangezien de opvolgende versies zelden backwards compatible zijn en het dus kennelijk toch steeds niet perfect was.

ThomasG schreef op donderdag 22 september 2016 @ 12:02:
[...]
Het probleem is dat Java helemaal geen generics heeft. Ja, "nep" generics. Want het is een compiler truc waarbij het wordt omgezet naar casts.

Het is een onderdeel van typechecking, waarom mag typechecking niet statisch? Dat heeft wat mij betreft de voorkeur. Het wordt trouwens niet omgezet naar casts: een generic typechecker toont juist type-safety aan zonder dat casts nodig zijn.

Als het niet voldoet aan de C-definitie van generics: nee, vast niet. C-generics voldoen ook niet aan de Java-definitie. Dat doet me denken aan de discussie of objecten in Java nou by-reference of by-value worden doorgegeven - vrij betekenisloos, als je de C-definities erop projecteert.

[CodeCaster]

incaz schreef op donderdag 22 september 2016 @ 13:17:
[...]


False dichotomy.

Helemaal niet. Ik ga ervan uit dat er iemand is die zijn mening wil geven over iets wat gepresenteerd wordt. Als je geen feedback wil, moet je niets presenteren. Iets presenteren impliceert dat je commentaar wil. Anders maak je maar een YouTube-video of schrijf je een blog, en zet je de mogelijkheid tot reageren en stemmen uit.

Dus je kunt mijn reacties wel uit elkaar trekken en met leuke termen gaan smijten die slaan op één zinnetje, maar dan mis je dus het plaatje dat ik verspreid over verschillende posts probeer te tekenen.

Dus, aangenomen dat er een persoon is die feedback wil, en een andere persoon die zijn feedback kwijt wil, ja, dán zijn er diverse manieren waarop laatstgenoemde dat kan doen, en zeker geen twee (hetzij met bloemetjes strooien, hetzij met uitwerpselen smijten). Dat laatste zeg ik ook nergens.

Zoals je ook uit mijn reacties kan teruglezen zie ík geen nut in denigrerende reacties, sterker nog, heb ik last van plaatsvervangende schaamte als die geplaatst worden. Aan de andere kant moet je, afhankelijk van de situatie, wellicht heroverwegen of je wel op de goede plek om feedback vraagt.

Dus ik mis het punt een beetje dat je wil maken.

[ Voor 38% gewijzigd door CodeCaster op 22-09-2016 13:35 ]

[Mercatres]

Woa, deze discussie is nogal meta aan het worden

---

Vandaag laatste puntjes op de i voor de sprintdemo, 't gaat weer een mooie worden

[incaz]

[quote]CodeCaster schreef op donderdag 22 september 2016 @ 13:29:
[...]

Of, met gestrekter been: als je aanstoot neemt aan een reactie zoals kenneth die plaatste, dan is de aanstootnemer schuldig aan het misinterpreteren.

'Schuldig' - wat een interessante woordkeuze.

Binnen iedere groep gelden andere normen en waarden, en je kunt niet verwachten dat iedere groep zich aanpast aan wat jij verwacht. De reactie was grappig bedoeld, wás grappig, en als je dat niet vindt, ligt dat aan jou.

Precies. Men wil heel graag de eigen groep gesloten houden en mensen die er anders over denken buiten sluiten: dat ligt aan jou als buitenstaander, niet aan ons als groep. Dat is precies het probleem.

[DevWouter]

farlane schreef op donderdag 22 september 2016 @ 12:07:
[...]

De gedachte is nog altijd dat er zo weinig mogelijk aannames worden gedaan op welk platform de binary terecht komt en dat je zo weinig mogelijk aannames doet over wat dat platform wel en niet kan.

Dat klopt, maar waar wil je met die opmerking heen? Ik kan me niet voorstellen dat je daarmee bedoelt dat het om die reden voor "oude systemen" bedoeld is. Met een risico dat we nog verder afdwalen: Ik vind het uitermate vervelend als een taal juist aannames doet. Maar goed dat is een mening en die zijn ook vervelend

.oisyn schreef op donderdag 22 september 2016 @ 12:16:
[...]

Dat is een redenatiefout - het een sluit het andere niet uit namelijk. C11 heeft nog steeds de bagage van 40 jaar geleden.

Maar dat zeg ik ook niet
Mijn stelling is juist dat C11 ontwikkeld is voor recentere systemen.

[RayNbow]

ThomasG schreef op donderdag 22 september 2016 @ 12:02:
[...]
Het probleem is dat Java helemaal geen generics heeft. Ja, "nep" generics. Want het is een compiler truc waarbij het wordt omgezet naar casts. Wanneer je Java compileert is er totaal geen verschil tussen een List<A> en List<B>. Enkel C# heeft de generics op bytecode niveau. (C++ templates zijn trouwens ook geen generics).

Het zijn nog steeds generics, alleen zijn de typeparameters niet reified.

ThomasG schreef op donderdag 22 september 2016 @ 12:07:
[...]
Nee, want Java weet runtime het verschil niet. Een code als:

Java:

public void Foo(List<Bar> bar);
public void Foo(List<Baz> baz);

Kan niet in Java. Als je het type wilt achterhalen van de generic, zal je dat in Java heel omslachtig moeten doen, omdat Java het zelf niet weet. Bij C# kan dat allemaal wel.

Behalve dat je geen runtimeinformatie nodig zou moeten hebben. Voor zo ver ik weet wordt method overload resolution statisch bepaald en zou de compiler dus in theorie de code zoals in Merethil in "De Devschuur Coffee Corner - Iteratie ➓" kunnen genereren.

[gekkie]

incaz schreef op donderdag 22 september 2016 @ 13:17:
[...]
Ook dat is een false dichotomy, alsof er niet meer dan 2 opties zijn ipv een glijdende schaal.

Net zoals er een glijende schaal is van een generieke dicussie over een taal, naar persoonlijke feedback op persoonlijke keuzes bij persoonlijk werk.

Vuurbal leek in eerste instantie over het eerste te beginnen, ondertussen lijken we bij het laatste beland.

Bij een generieke discussie met kritiek lijkt het me toch niet zo gek dat als mensen:
- dat geheel op zich zelf en de keuzes die ze maken betrekken
- het dus als feedback zien
- en daar ook nog depressief van raken
dat mensen daar dan de feedback op geven dat dat wellicht in zich zelf niet zo'n handige keuze is ?

Daarbij sluit het uiten van de mening "PHP is kut" in mijn ogen geenzins uit dat je er best iets prima functionerends en moois in kunt maken (in iedergeval in de functionaliteit, in de code is het behalen van enige elegantie al een stuk moeilijker mijns inziens). Sterker nog, je zou het ook als een prestatie kunnen zien.
Kortom wat is toch de ogenschijnlijk toenemende hang naar alles heel persoonlijk te nemen en op jezelf te betrekken, terwijl dat vaak meer of minder duidelijk niet de intentie was van de boodschapper?
(en daarbij dus steeds vanzelfsprekender lijkt te zijn geworden om intenties (overigens zowel positief als negatief) volledig te negeren.)

[farlane]

DevWouter schreef op donderdag 22 september 2016 @ 13:55:
Dat klopt, maar waar wil je met die opmerking heen?

Jij schrijft dat ik bullcrap uitkraam, volgens mij deed ik dat niet. C11 is inderdaad niet voor systemen van 40 jaar geleden bedacht, maar heeft nog diezelfde uitgangspunten en daarom zit het er nog altijd niet in en het zal waarschijnlijk ook niet gebeuren mede doordat die beslissing 40 jaar geleden gemaakt is.

Da's alles wat ik zeggen wil.

[Laurens-R]

Gloeiende gloeiende... heeft iemand anders mijn afvalcontainer meegenomen

[DevWouter]

farlane schreef op donderdag 22 september 2016 @ 15:09:
[...]

Jij schrijft dat ik bullcrap uitkraam, volgens mij deed ik dat niet. C11 is inderdaad niet voor systemen van 40 jaar geleden bedacht, maar heeft nog diezelfde uitgangspunten en daarom zit het er nog altijd niet in en het zal waarschijnlijk ook niet gebeuren mede doordat die beslissing 40 jaar geleden gemaakt is.

Da's alles wat ik zeggen wil.

Helemaal met je eens, hoewel ik 40 jaar nog steeds iets overdreven vind, maar dat is azijn zeiken om het azijn zeiken en volgens mij heb ik mijn quota voor vandaag al gehaald.

Oh en Bullcrap is een reactionele uitspraak (net zoals dat overdreven "O-M-G") en niet een oordeel, maar ik had al eerder aangegeven dat het niet zo slimme uitspraak was

[.Gertjan.]

F*ck... Volgens mij heeft Windows hun activation(-server) gesloopt... Ineens flippen een aantal laptops hier dat hun keys niet geldig zijn en dus niet activated zijn. Een deel roept vrolijk dat de systemen geen goede key hebben en een ander deel dat ze niet activated zijn tijdens hun W8 tijd... Vreemd, want het eerste wat we doen is Windows activaten voordat we de laptops uberhaubt overhandigen... Daarnaast zijn ze ook al een redelijk lange tijd in gebruik (voor juni toen Microsoft de stekker uit de free W10 upgrade trok)...

Eens even kijken of het probleem zichzelf oplost... Anders mogen we weer de support-pet opzetten...

[bwerg]

.Gertjan. schreef op donderdag 22 september 2016 @ 15:47:
F*ck... Volgens mij heeft Windows hun activation(-server) gesloopt

Je moet ook geen gecrackte versies op bedrijfslaptops zetten.

[Jegorex]

Laurens-R schreef op donderdag 22 september 2016 @ 15:32:
Gloeiende gloeiende... heeft iemand anders mijn afvalcontainer meegenomen

Is mij ook een paar keer overkomen.
Een dag wachten totdat er 1 container over is en je hebt de dader. (Zolang er een adres/huisnummer op staat)

[gekkie]

.Gertjan. schreef op donderdag 22 september 2016 @ 15:47:
F*ck... Volgens mij heeft Windows hun activation(-server) gesloopt... Ineens flippen een aantal laptops hier dat hun keys niet geldig zijn en dus niet activated zijn. Een deel roept vrolijk dat de systemen geen goede key hebben en een ander deel dat ze niet activated zijn tijdens hun W8 tijd... Vreemd, want het eerste wat we doen is Windows activaten voordat we de laptops uberhaubt overhandigen... Daarnaast zijn ze ook al een redelijk lange tijd in gebruik (voor juni toen Microsoft de stekker uit de free W10 upgrade trok)...

Eens even kijken of het probleem zichzelf oplost... Anders mogen we weer de support-pet opzetten...

Ah ooit gehad met windows vista .. terwijl er een groepje hotemetoten van een klant achter die laptops zat. Middagje kunnen afmaken met om het ik meende 2 uur een reboot en vol in beeld dat het vermoedelijk een illlegale versie betrof. Uiteindelijk met MS mogen bellen om al die krengen weer geactiveerd te krijgen want ze hadden er echt geen zin meer in om geactiveerd te geraken.

[.Gertjan.]

bwerg schreef op donderdag 22 september 2016 @ 15:50:
[...]
Je moet ook geen gecrackte versies op bedrijfslaptops zetten.

Of juist wel, daar sloop je gewoon dat soort onzinnigheid uit. Alle laptops zijn netjes licensed met een W8 Home (installed) -> W8 pro upgrade -> W10 pro upgrade. Keys hebben tot voor kort prima gewerkt op de betreffende laptops, dus dat maakt het helemaal vreemd...

[Skyaero]

Laurens-R schreef op donderdag 22 september 2016 @ 15:32:
Gloeiende gloeiende... heeft iemand anders mijn afvalcontainer meegenomen

Ik dacht eerst dat dit een pun was naar een niet-werkende GarbageCollector.

Tijd om naar huis te gaan denk ik zo.

[raptorix]

Zucht al een kleine dag bezig met de API van Confluence, neem je 1 op 1 een Curl voorbeeld over, maar werkt gewoon niet

[dcm360]

Ik zat net met een vergelijkbaar probleem. Een (php)-curl voorbeeld gevonden om een bestand te uploaden via WebDav, maar dat bleek toch niet helemaal te doen wat de WebDav-implementatie van OwnCloud verwacht. Geen idee welke van de twee afwijkt, maar na een tijdje puzzelen bleek dat CURLAUTH_ANY vervangen door CURLAUTH_BASIC het probleem oploste.

[RayNbow]

RayNbow schreef op donderdag 22 september 2016 @ 13:56:
[...]

Behalve dat je geen runtimeinformatie nodig zou moeten hebben. Voor zo ver ik weet wordt method overload resolution statisch bepaald en zou de compiler dus in theorie de code zoals in Merethil in "De Devschuur Coffee Corner - Iteratie ➓" kunnen genereren.

Alternatief, dummywaardes als tags om de juiste methode te kiezen:

Java:

import java.util.*;

class MRO
{
    
    class Bar {}
    class Baz {}
    
    public static void Foo(List<Bar> bar, Bar tag) {
        System.out.println("Bar");
    }
    public static void Foo(List<Baz> baz, Baz tag) {
        System.out.println("Baz");
    }
    
    public static void main (String[] args) {
        List<Bar> bar = new ArrayList<Bar>();
        List<Baz> baz = new ArrayList<Baz>();
        
        Foo(bar, true ? null : bar.get(0));
        Foo(baz, true ? null : baz.get(0));
    }
}

Dus geen runtime-informatie nodig in dit geval.

[F.West98]

RayNbow schreef op donderdag 22 september 2016 @ 19:37:
[...]

Alternatief, dummywaardes als tags om de juiste methode te kiezen:

Java:

import java.util.*;

class MRO
{
    
    class Bar {}
    class Baz {}
    
    public static void Foo(List<Bar> bar, Bar tag) {
        System.out.println("Bar");
    }
    public static void Foo(List<Baz> baz, Baz tag) {
        System.out.println("Baz");
    }
    
    public static void main (String[] args) {
        List<Bar> bar = new ArrayList<Bar>();
        List<Baz> baz = new ArrayList<Baz>();
        
        Foo(bar, true ? null : bar.get(0));
        Foo(baz, true ? null : baz.get(0));
    }
}

Dus geen runtime-informatie nodig in dit geval.

Iets als typeof(T) kan in C# wel gewoon, in Java kan dat niet. Dan moet je dus een Class instance gaan meegeven:

Java:

void someFunc<T>(T some, Class<T> type) {}
someFunc(foo, foo.getType());

Ofzo, geen idee wat de precieze syntax is want ik doe niet zo veel generics in Java

[Merethil]

F.West98 schreef op donderdag 22 september 2016 @ 21:41:
[...]

Iets als typeof(T) kan in C# wel gewoon, in Java kan dat niet. Dan moet je dus een Class instance gaan meegeven:

Java:

void someFunc<T>(T some, Class<T> type) {}
someFunc(foo, foo.getType());

Ofzo, geen idee wat de precieze syntax is want ik doe niet zo veel generics in Java

Java:

void <T> someFunc(T some) {}
someFunc(foo);

De class haalt ie van je paramater, dus die hoef je niet nog apart mee te geven.

En ja, dat werkt op zich prima. Die dummy-variant zat ik eerder ook aan te denken. Mijn vraag met waarom je zoiets wilt kunnen doen is echter nog steeds niet beantwoord

[ Voor 7% gewijzigd door Merethil op 22-09-2016 21:59 ]

[F.West98]

Merethil schreef op donderdag 22 september 2016 @ 21:49:
[...]

Java:

void <T> someFunc(T some) {}
someFunc(foo);

De class haalt ie van je paramater, dus die hoef je niet nog apart mee te geven.

En ja, dat werkt op zich prima. Die dummy-variant zat ik eerder ook aan te denken. Mijn vraag met waarom je zoiets wilt kunnen doen is echter nog steeds niet beantwoord

Als je de type of T wil weten. Bijvoorbeeld in iets als dit (ja, kan netter, maar gaat om het idee) of dit (in dit geval wil ik filteren op elementen - ergo alleen maar elementen van type T zoeken. Om dan te kunnen filteren erop heb ik het type ervan nodig, omdat T geen variable/watdanook is, dus moet ik het type handmatig meegeven. In C# kan je gewoon x instanceof T oid doen.)
TL;DR: Je kan niet bepalen of een object een instance of een generic type is zonder het type-object.

[Caelorum]

Man o man o man... jongens toch... die laatste pagina's! Aan de ene kant een hele interessante discussie en aan de andere kant moraalridders en antichrists die aan het bekvechten zijn... echt WTF?

[BarôZZa]

gekkie schreef op donderdag 22 september 2016 @ 14:40:
[...]

Daarbij sluit het uiten van de mening "PHP is kut" in mijn ogen geenzins uit dat je er best iets prima functionerends en moois in kunt maken (in iedergeval in de functionaliteit, in de code is het behalen van enige elegantie al een stuk moeilijker mijns inziens). Sterker nog, je zou het ook als een prestatie kunnen zien.

Wat versta jij onder elegantie? Voor mij is het voornamelijk fatsoenlijk OOP werken, abstractie en de juiste patterns toepassen. Allemaal prima mogelijk met PHP tegenwoordig. De elegantie zit hem vaak in de eenvoud en het weglaten van (in veel gevallen) onnodige complexiteit. Zelf zie ik liever dat $string1 . $string2 dan dit soort zaken:

code:

NSString *s = @"Hallo";
s = [s stringByAppendingString:@" Piet"];
NSLog(@"%@", s);

Al moet ik zeggen dat het eindresultaat/functionaliteit/snelheid/gebruiksgemak voor mij altijd flink hoger staat dan de netheid van de code. Nette code is een goed middel, maar geen doel op zich en verre van een garantie. In de meest nette code worden vaak de meest onlogische dingen gedaan.

[RayNbow]

F.West98 schreef op donderdag 22 september 2016 @ 22:22:
[...]

Als je de type of T wil weten.

Het idee van generics is doorgaans dat je generieke code wilt schrijven. Dan zou het niet uit moeten maken wat T is.

[F.West98]

RayNbow schreef op donderdag 22 september 2016 @ 23:02:
[...]

Het idee van generics is doorgaans dat je generieke code wilt schrijven. Dan zou het niet uit moeten maken wat T is.

C#:

someList.Where(s => s instanceof T);

Lijkt me toch vrij generieke code. Je hoeft T niet te weten, het maakt niet uit wat het is. De code werkt.
Maar niet in Java dus.

[Merethil]

F.West98 schreef op donderdag 22 september 2016 @ 22:22:
[...]

Als je de type of T wil weten. Bijvoorbeeld in iets als dit (ja, kan netter, maar gaat om het idee) of dit (in dit geval wil ik filteren op elementen - ergo alleen maar elementen van type T zoeken. Om dan te kunnen filteren erop heb ik het type ervan nodig, omdat T geen variable/watdanook is, dus moet ik het type handmatig meegeven. In C# kan je gewoon x instanceof T oid doen.)
TL;DR: Je kan niet bepalen of een object een instance of een generic type is zonder het type-object.

Dat snap ik, ik gebruik zelf vrij vaak generics. Mijn vraag ging echter over waarom ik dit zou willen doen:

Java:

void Foo(List<baz> baz);
void Foo(List<bar> bar);

Java kan dit niet. Maar waarom moet je het willen? Lekker duidelijk, zelfde naam, andere input en met een soortgelijke naamgeving voor je lists ook nog eens lekker onduidelijk voor je collega's/nakomelingen.
Mijn vraag was waarom je niet gewoon onderscheid zou maken tussen die twee Foo() functies / methods door de naam iets duidelijker te maken. Wat is het praktisch nut van de code in kwestie?

Edit: het hele punt van generics is echter dat je zo min mogelijk probeert te casten of specifieke code voor specifieke classes te schrijven lijkt mij. Generics horen juist iets te doen wat op alle classes/objects van toepassing horen te kunnen zijn, juist daarom zou het gaan om generics. Anders kan je net zo goed je functie zo bouwen dat ie alleen werkt voor jouw type en diens sub-/superclasses.

[ Voor 12% gewijzigd door Merethil op 23-09-2016 06:25 ]

[RayNbow]

F.West98 schreef op donderdag 22 september 2016 @ 23:05:
[...]

C#:

someList.Where(s => s instanceof T);

Geen .OfType<T>()?

Lijkt me toch vrij generieke code. Je hoeft T niet te weten, het maakt niet uit wat het is. De code werkt.
Maar niet in Java dus.

Maar wat doe je vervolgens met het resultaat waarin T een rol speelt? Blijkbaar is someList een List<S> where T : S of misschien zelfs een niet-generieke List. Je kunt je dan afvragen waarom someList niet beter een List<T> had kunnen zijn.

[Merethil]

RayNbow schreef op vrijdag 23 september 2016 @ 06:44:
[...]

Geen .OfType<T>()?

[...]

Maar wat doe je vervolgens met het resultaat waarin T een rol speelt? Blijkbaar is someList een List<S> where T : S of misschien zelfs een niet-generieke List. Je kunt je dan afvragen waarom someList niet beter een List<T> had kunnen zijn.

Het is waarschijnlijk zo'n beetje hetzelfde als waar de boel mee begon: Je wilt uit een lijst van Food alle Apples halen bijvoorbeeld. Echter, volgens mij heb je daar niet specifiek generics voor nodig maar kan je prima dat als oneline in je code laten staan:

Java:

List<Food> foods = new ArrayList<>();
        
foods.add(new Apple());
foods.add(new Apple());
foods.add(new Apple());
foods.add(new Banana());
foods.add(new Banana());
        
List<Apple> apples = foods.stream().filter(s -> s instanceof Apple).map(s -> (Apple) s).collect(Collectors.toList());

apples.stream().forEach(s -> System.out.println(s.getName())); // returns 3x Apple

F.West98 schreef op donderdag 22 september 2016 @ 23:05:
[...]

C#:

someList.Where(s => s instanceof T);

Lijkt me toch vrij generieke code. Je hoeft T niet te weten, het maakt niet uit wat het is. De code werkt.
Maar niet in Java dus.

Blijkbaar kan 't toch wel:

Java:

private <T> List<T> getTypeListFromList(List<?> list, Class<T> type) {
    List<T> newList = new ArrayList<>();
        
    newList = list.stream().filter(type::isInstance).map(s -> (T) s).collect(Collectors.toList());
        
    return newList;
}

Op zich vind ik het niet heel netjes, vooral omdat je een cast doet, maar die kan je prima doen omdat je al gefilterd hebt.
Nadat ik deze function probeerde met mijn lijst van foods en als Class<T> banana meegegeven heb, krijg ik inderdaad een lijst van Banana's terug.

[ Voor 3% gewijzigd door Merethil op 23-09-2016 07:22 ]

[RayNbow]

Iets anders:

[.Gertjan.]

Merethil schreef op vrijdag 23 september 2016 @ 06:21:
[...]

Java:

void Foo(List<baz> baz);
void Foo(List<bar> bar);

Edit: het hele punt van generics is echter dat je zo min mogelijk probeert te casten of specifieke code voor specifieke classes te schrijven lijkt mij. Generics horen juist iets te doen wat op alle classes/objects van toepassing horen te kunnen zijn, juist daarom zou het gaan om generics. Anders kan je net zo goed je functie zo bouwen dat ie alleen werkt voor jouw type en diens sub-/superclasses.

De ene lijst is de andere niet In dit geval gebruik je List enkel als data-opslag en ga je waarschijnlijk verder niets met de lijst doen, maar met de items in de lijst. Dan is je structuur volgens mij wel logisch. Ga je specifiek iets met de list zelf doen, dan zou ik zelfs niet naar de generic oplossing grijpen, maar naar IList of iets dergelijks.

Ik zit even te denken over een situatie waarin je dit zou willen doen. Misschien als je iets wil optellen vanuit de items in de lijst, bijvoorbeeld afboeken van data in een inventory. Dan kan het zijn dat je List<Product> en List<Part> zou hebben als input, maar waarschijnlijk fiets je daar een interface omheen zodat je een List<IInventoryItem> kan meegeven.

Wel grappig dat Java dit niet leuk vind en .NET wel. Nu weet ik dat .NET op de achtergrond een class per generic implementatie maakt (ListOfBaz en ListOfBar), ben benieuwd hoe Java dat dan doet.

[Ryur]

Wilt er iemand een verkoudheid? Mogelijk groeiend naar een griep.
Gratis af te halen!

(Toevallig had ik vandaag al een thuiswerkdag gepland staan, maar dit heb ik maar veranderd in een ziektedag. Ben zo moe & wazig vandaag)

[RayNbow]

.Gertjan. schreef op vrijdag 23 september 2016 @ 09:15:
Wel grappig dat Java dit niet leuk vind en .NET wel. Nu weet ik dat .NET op de achtergrond een class per generic implementatie maakt (ListOfBaz en ListOfBar),

In feite doet .NET dat alleen voor value types ([1], [2]). Voor reference types wordt er code gedeeld (en wordt er alleen metadata over de typeparameters opgeslagen in het object).

ben benieuwd hoe Java dat dan doet.

In Java zijn een C<T> en een C<S> gelijk aan een C<Object> (type erasure). Generics bestaan in Java alleen tijdens het compileren.

[ Voor 0% gewijzigd door RayNbow op 23-09-2016 11:25 . Reden: typo ]

[ZaZ]

Ryur schreef op vrijdag 23 september 2016 @ 09:21:
Wilt er iemand een verkoudheid? Mogelijk groeiend naar een griep.
Gratis af te halen!

(Toevallig had ik vandaag al een thuiswerkdag gepland staan, maar dit heb ik maar veranderd in een ziektedag. Ben zo moe & wazig vandaag)

Nee bedankt, ben 'm net de deur aan het uitwerken.

[Zelalas]

Ryur schreef op vrijdag 23 september 2016 @ 09:21:
Wilt er iemand een verkoudheid? Mogelijk groeiend naar een griep.
Gratis af te halen!

(Toevallig had ik vandaag al een thuiswerkdag gepland staan, maar dit heb ik maar veranderd in een ziektedag. Ben zo moe & wazig vandaag)

Beterschap en nee bedankt. Ik wil niet geïnfecteerd worden.

Ach, vandaag een dagje testwerkzaamheden ipv programmeren. Iets met T shaped person.

[DevWouter]

Caelorum schreef op donderdag 22 september 2016 @ 22:56:
Man o man o man... jongens toch... die laatste pagina's! Aan de ene kant een hele interessante discussie en aan de andere kant moraalridders en antichrists die aan het bekvechten zijn... echt WTF?

Gewoon die popcorn doorgeven en hopen dat het vervolg beter is.

[Merethil]

.Gertjan. schreef op vrijdag 23 september 2016 @ 09:15:
[...]

De ene lijst is de andere niet In dit geval gebruik je List enkel als data-opslag en ga je waarschijnlijk verder niets met de lijst doen, maar met de items in de lijst. Dan is je structuur volgens mij wel logisch. Ga je specifiek iets met de list zelf doen, dan zou ik zelfs niet naar de generic oplossing grijpen, maar naar IList of iets dergelijks.

Ik zit even te denken over een situatie waarin je dit zou willen doen. Misschien als je iets wil optellen vanuit de items in de lijst, bijvoorbeeld afboeken van data in een inventory. Dan kan het zijn dat je List<Product> en List<Part> zou hebben als input, maar waarschijnlijk fiets je daar een interface omheen zodat je een List<IInventoryItem> kan meegeven.

Wel grappig dat Java dit niet leuk vind en .NET wel. Nu weet ik dat .NET op de achtergrond een class per generic implementatie maakt (ListOfBaz en ListOfBar), ben benieuwd hoe Java dat dan doet.

Mijn vraag blijft: Waarom zou je die dingen niet los van elkaar een ander naampje geven? DoFooWithBaz en DoFooWithBar is in ieder geval al duidelijker dan Foo(List<Baz>) of Foo(List<Bar>). Alleen al qua leesbaarheid.
Waarom, waarom, waarom moeten die functies in dezelfde class hetzelfde heten? Waarom wil je dat? Ik bedoel dus aan te duiden dat dat soort ongein "waarom Java slecht zou zijn" geen reden is, want wanneer ga je nou in hemelsnaam exact dezelfde functienaam voor twee verschillende, maar evenveel, parameters bouwen?
Kijk, als er nou daadwerkelijk overloading plaatsvindt: OK. Maar dit voorbeeld is echt niet logisch imo.

[.oisyn]

RayNbow schreef op vrijdag 23 september 2016 @ 09:33:
[...]

(\[2]).

Interesting read, maar er wordt niet echt een fair plaatje van C++ templates gegeven door met termen als loose typing te smijten .

Maar het is natuurlijk wel een MS meneer, en de templates implementatie van VC++ was altijd een beetje een cop-out (ze slaan gewoon de tokenstream op en ze gaan pas echt parsen bij instantiation als alle template parameters bekend zijn, wat niet helemaal de bedoeling is en waardoor dingen als two-phase name lookup niet zijn te implementeren). Ik geloof dat ze dat voor VS 15 gaan fixen.

[ Voor 41% gewijzigd door .oisyn op 23-09-2016 11:33 ]

[jbdeiman]

Merethil schreef op vrijdag 23 september 2016 @ 11:24:
[...]


Mijn vraag blijft: Waarom zou je die dingen niet los van elkaar een ander naampje geven? DoFooWithBaz en DoFooWithBar is in ieder geval al duidelijker dan Foo(List<Baz>) of Foo(List<Bar>). Alleen al qua leesbaarheid.
Waarom, waarom, waarom moeten die functies in dezelfde class hetzelfde heten? Waarom wil je dat? Ik bedoel dus aan te duiden dat dat soort ongein "waarom Java slecht zou zijn" geen reden is, want wanneer ga je nou in hemelsnaam exact dezelfde functienaam voor twee verschillende, maar evenveel, parameters bouwen?
Kijk, als er nou daadwerkelijk overloading plaatsvindt: OK. Maar dit voorbeeld is echt niet logisch imo.

Eens, het is logisch dezelfde functienaam te gebruiken wanneer bepaalde parameters "optioneel" zijn, maar totaal verschillende parameters (en typen) is absoluut niet logisch. Het zijn daarmee 2 totaal verschillende functies geworden, die ook daadwerkelijk wat anders zouden moeten doen.
Mij is ook altijd geleerd dat een functie-naam moet beschrijven wat de functie doet, doordat je 2 verschillende typen parameters meegeeft is dat nu niet erg leesbaar / handig meer.

Zelfs als het om een sortering gaat van een list met inhoudstype <Baz> en <Bar>, zou ik kiezen voor "sortBaz" en "sortBar", dit omdat je typen volledig andere inhoud (en opbouw) kunnen hebben en je door een duidelijker naamgeving er meteen voor zorgt dat de kans op fouten kleiner wordt.

[Hydra]

.Gertjan. schreef op vrijdag 23 september 2016 @ 09:15:
Wel grappig dat Java dit niet leuk vind en .NET wel. Nu weet ik dat .NET op de achtergrond een class per generic implementatie maakt (ListOfBaz en ListOfBar), ben benieuwd hoe Java dat dan doet.

Niks grappigs aan helaas. Dit is gedaan om generics (die er in Java 5 pas bijgekomen zijn) compatible te houden met oudere runtimes. Dit is ook een keuze waar, hoewel het logisch is, een hoop mensen van balen. De implementatie van .Net is hier gewoon objectief beter; generics hadden vanaf versie 1 in Java moeten zitten. Gewoon een foute keuze dus.

En method overloading is gewoon handig. Dit levert in het wil best vaak problemen op. Zo werken optionals hierdoor een stuk lastiger:

Java:

public void doSomething(Optional<Foo> opt)

public void doSomething(Optional<Bar> opt)

Het zou fijn zijn als dit kon i.p.v. nullable parameters te gebruiken maar in Java is dit onmogelijk, in .Net niet. Die post geeft ook nog een erg goed voorbeeld hoe hierdoor generics niet in throwables gebruikt kunnen worden.

[ Voor 23% gewijzigd door Hydra op 23-09-2016 11:37 ]

[Merethil]

Hydra schreef op vrijdag 23 september 2016 @ 11:34:
[...]


Niks grappigs aan helaas. Dit is gedaan om generics (die er in Java 5 pas bijgekomen zijn) compatible te houden met oudere runtimes. Dit is ook een keuze waar, hoewel het logisch is, een hoop mensen van balen. De implementatie van .Net is hier gewoon objectief beter; generics hadden vanaf versie 1 in Java moeten zitten. Gewoon een foute keuze dus.

En method overloading is gewoon handig. Dit levert in het wil best vaak problemen op. Zo werken optionals hierdoor een stuk lastiger:

Java:

public void doSomething(Optional<Foo> opt)

public void doSomething(Optional<Bar> opt)

Het zou fijn zijn als dit kon i.p.v. nullable parameters te gebruiken maar in Java is dit onmogelijk, in .Net niet. Die post geeft ook nog een erg goed voorbeeld hoe hierdoor generics niet in throwables gebruikt kunnen worden.

Maar wat is nou een logische usecase van dit type overloading? In het ergste geval, mocht je het echt nodig hebben, kan je generics gebruiken om daarin te checken op type, maar ik ben nog nooit een specifiek probleem tegengekomen waar ik de door jou aangegeven code echt nodig zou hebben.

[Hydra]

Merethil schreef op vrijdag 23 september 2016 @ 11:44:

Maar wat is nou een logische usecase van dit type overloading? In het ergste geval, mocht je het echt nodig hebben, kan je generics gebruiken om daarin te checken op type

Je vraagt nu eigenlijk wat het nut is van method overloading. Als het nuttig is op gewone types is het ook nuttig op generic types. Als je in mijn voorbeeld de Optional weghaalt werkt het wel.

En ja, wat je zegt kan ook. En dat levert dus gewoon ranzige if(foo instanceOf SomeType) op die ook nog eens niet werkt als een parameter null is (want instanceof werkt niet op een null value).

Alles kan. Je hebt ook geen for loops nodig; het werkt ook prima met een goto. Maar een generic type is nog steeds een type en als je wil overloaden op type en het op gewone types wel werkt en op generic types niet dan krijg je dus helaas in Java inconsistente prut.

Edit: nog een issue van type erasure: interface pollution.

[ Voor 7% gewijzigd door Hydra op 23-09-2016 11:50 ]

[Merethil]

Hydra schreef op vrijdag 23 september 2016 @ 11:47:
[...]


Je vraagt nu eigenlijk wat het nut is van method overloading. Als het nuttig is op gewone types is het ook nuttig op generic types. Als je in mijn voorbeeld de Optional weghaalt werkt het wel.

En ja, wat je zegt kan ook. En dat levert dus gewoon ranzige if(foo instanceOf SomeType) op die ook nog eens niet werkt als een parameter null is (want instanceof werkt niet op een null value).

Alles kan. Je hebt ook geen for loops nodig; het werkt ook prima met een goto. Maar een generic type is nog steeds een type en als je wil overloaden op type en het op gewone types wel werkt en op generic types niet dan krijg je dus helaas in Java inconsistente prut.

Edit: nog een issue van type erasure: interface pollution.

Ik zeg ook niet dat het geweldig is dat het erin zit: het is gewoon crap. Maar waarom kan niemand een normale usecase leveren waardoor ik kan begrijpen wanneer je dit wilt voor zoiets als een list. En waarom het zo vreselijk is om aan je method een ander naampje te geven om te onderscheiden ipv dit te doen.

[.oisyn]

Merethil schreef op vrijdag 23 september 2016 @ 11:56:
Maar waarom kan niemand een normale usecase leveren waardoor ik kan begrijpen wanneer je dit wilt voor zoiets als een list.

Waarom wil je zo'n specifiek arbitrair voorbeeld dat gebruikt maakt van een list? De issue ging over generic types in het algemeen.

En waarom het zo vreselijk is om aan je method een ander naampje te geven om te onderscheiden ipv dit te doen.

Je wilt toch beschrijven wat de functie doet, niet wat er in wordt gestopt? Dat is nutteloze clutter. Kijk, als de functie daadwerkelijk iets heel anders doet, dan moet het een andere naam krijgen. Maar als beide overloads hetzelfde doel hebben, dan is een overload gewoon een normale keuze.

En dan heb je nog constructors, die kún je niet eens een andere naam geven. Dan moet je met static functies gaan goochelen.

[Merethil]

.oisyn schreef op vrijdag 23 september 2016 @ 12:05:
[...]

Waarom wil je zo'n specifiek arbitrair voorbeeld dat gebruikt maakt van een list? De issue ging over generic types in het algemeen.


[...]

Je wilt toch beschrijven wat de functie doet, niet wat er in wordt gestopt? Dat is nutteloze clutter. Kijk, als de functie daadwerkelijk iets heel anders doet, dan moet het een andere naam krijgen. Maar als beide overloads hetzelfde doel hebben, dan is een overload gewoon een normale keuze.

En dan heb je nog constructors, die kún je niet eens een andere naam geven. Dan moet je met static functies gaan goochelen.

Het ging me meer om een bruikbaar voorbeeld in het algemeen, niet zozeer met lists specifiek. Constructors kan ik nog begrijpen, al snap ik niet waarom je twee verschillende constructors wilt hebben met twee verschillende generics, maar goed dat zal wel door mijn gebrek aan ervaring komen.

Ik zal erover ophouden, blijkbaar snap ik het gewoon niet.

[DevWouter]

Ik wil templates in C#. Generics zijn cool, maar templates zou best handig zijn van tijd tot tijd

[Hydra]

Merethil schreef op vrijdag 23 september 2016 @ 11:56:
Ik zeg ook niet dat het geweldig is dat het erin zit: het is gewoon crap. Maar waarom kan niemand een normale usecase leveren waardoor ik kan begrijpen wanneer je dit wilt voor zoiets als een list. En waarom het zo vreselijk is om aan je method een ander naampje te geven om te onderscheiden ipv dit te doen.

Het is een workaround voor een probleem dat niet had moeten bestaan. Je noemt je andere methods toch ook niet naar de parameters die er in gaan? En wat als je er 4 hebt ofzo? Dan krijg je

Java:

doListOfStringsAndListOfIntegersAndListOfDoublesAndListOfObjects(List<String> l1, List<Integer> l2, List<Double> l3, List<Object> l4)

in plaats van gewoon

Java:

do(List<String> l1, List<Integer> l2, List<Double> l3, List<Object> l4)

Het kan allemaal prima. Maar het is gewoon rommelig en het was mooier geweest als het niet nodig was. En in het geval van exception handling is het echt ruk dat je geen generic exceptions kunt gebruiken.

Komt nog eens bij dat method overloading een soort pattern matching is. In Scala (waar types reified zijn) is dat enorm krachtig.

Merethil schreef op vrijdag 23 september 2016 @ 12:14:
Het ging me meer om een bruikbaar voorbeeld in het algemeen, niet zozeer met lists specifiek.

Ik heb je twee voorbeelden gegeven: optionals en generic throwables. Dat zijn dingen die je echt wel in 't wild tegenkomt als Java dev.

[ Voor 13% gewijzigd door Hydra op 23-09-2016 12:19 ]

[.oisyn]

Merethil schreef op vrijdag 23 september 2016 @ 12:14:
[...]


Het ging me meer om een bruikbaar voorbeeld in het algemeen, niet zozeer met lists specifiek. Constructors kan ik nog begrijpen, al snap ik niet waarom je twee verschillende constructors wilt hebben met twee verschillende generics, maar goed dat zal wel door mijn gebrek aan ervaring komen.

Ik zal erover ophouden, blijkbaar snap ik het gewoon niet.

Imho denk je veel te concreet. Wil je overloading op types? Ja. Waarom zou je dat dan ineens niet meer willen met generic types?

Maar goed, voorbeeld. Stel je hebt een factuur gemodeleerd met de klasse Invoice. Je bedrijf dealt zowel met personen (Person) als met andere bedrijven (Company), en als je de factuur wilt emailen dan doe je dat voor beide entiteiten in een verschillende vorm. Goed, je klasse Invoice heeft dus een method sendEmail(), die is geöverload op Person en Company.

Welnu, je applicatie deed eerst niets met databases, maar nu wil je de boel virtualizeren naar een willekeurige database, en je gebruikt daarvoor een een of andere (eventueel zelfgeschreven) library die gebruik maakt van generics om proxy classes te maken voor je objecten. Laten we die voor de grap even Accessor<> noemen. Nu heb je dus een Accessor<Person> en een Accessor<Company>, maar nu kun je je sendEmail() ineens niet meer overloaden in Java want door type erasure zijn beide types eigenlijk gewoon dezelfde.

[Merethil]

Hydra schreef op vrijdag 23 september 2016 @ 12:17:
[...]


Het is een workaround voor een probleem dat niet had moeten bestaan. Je noemt je andere methods toch ook niet naar de parameters die er in gaan? En wat als je er 4 hebt ofzo? Dan krijg je

Java:

doListOfStringsAndListOfIntegersAndListOfDoublesAndListOfObjects(List<String> l1, List<Integer> l2, List<Double> l3, List<Object> l4)

in plaats van gewoon

Java:

do(List<String> l1, List<Integer> l2, List<Double> l3, List<Object> l4)

Het kan allemaal prima. Maar het is gewoon rommelig en het was mooier geweest als het niet nodig was. En in het geval van exception handling is het echt ruk dat je geen generic exceptions kunt gebruiken.

Komt nog eens bij dat method overloading een soort pattern matching is. In Scala (waar types reified zijn) is dat enorm krachtig.

Lekker overtrokken weer, natuurlijk zeg ik dat niet. Ik zeg alleen dat het op die manier duidelijker wordt wanneer je tweemaal Foo() hebt, die zowel met een list van Bar als een list van Baz kan werken. Tussen die twee kan je natuurlijk prima onderscheid maken in naam, omdat ze allebei daadwerkelijk wat anders doen, ze hebben namelijk een volledig andere input (ook al denkt Java dat het niet zo is).

Als van jouw

Java:

do(List<String> l1, List<Integer> l2, List<Double> l3, List<Object> l4)

er nou meerdere zijn, die allemaal toevallig een set van vier lijsten maar met verschillende types als parameter nodig hebben, tja... Ik zie dat niet snel voorkomen.
Wel zie ik voorkomen:

Java:

do(List<String> l1);

do(List<String> l1, List<Integer> l2);

do(List<String> l1, List<Integer> l2, List<Double> l3);

do(List<String> l1, List<Integer> l2, List<Double> l3, List<Object> l4);

Nu heb ik geen jarenlange ervaring (nu net 6 jaar waarvan 2 jaar school, 4 jaar professioneel), maar ik ben alleen bovenstaande tot nu toe echt tegengekomen.

Ik heb je twee voorbeelden gegeven: optionals en generic throwables. Dat zijn dingen die je echt wel in 't wild tegenkomt als Java dev.

En bij allebei kon ik geen verhaal verzinnen wanneer het een issue oplevert. Allebei tegengekomen, maar het probleem in kwestie zelf nog nooit. Dat is ook de reden dat ik vroeg om een kwantificeerbare usecase; ik heb gewoon nog nooit zoiets meegemaakt alszijnde een obstakel en dus wilde ik er meer over weten.

.oisyn schreef op vrijdag 23 september 2016 @ 12:26:
[...]


Imho denk je veel te concreet. Wil je overloading op types? Ja. Waarom zou je dat dan ineens niet meer willen met generic types?

Maar goed, voorbeeld. Stel je hebt een factuur gemodeleerd met de klasse Invoice. Je bedrijf dealt zowel met personen (Person) als met andere bedrijven (Company), en als je de factuur wilt emailen dan goet je dat voor beide entiteiten in een verschillende vorm. Goed, je klasse Invoice heeft dus een method sendEmail(), die is geöverload op Person en Company.

Welnu, je applicatie deed eerst niets met databases, maar nu wil je de boel virtualizeren naar een willekeurige database, en je gebruikt daarvoor een een of andere (eventueel zelfgeschreven) library die gebruik maakt van generics om proxy classes te maken voor je objecten. Laten we die voor de grap even Accessor<> noemen. Nu heb je dus een Accessor<Person> en een Accessor<Company>, maar nu kun je je sendEmail() ineens niet meer overloaden in Java want door type erasure zijn beide types eigenlijk gewoon dezelfde.

Kijk, een voorbeeld dat ik daadwerkelijk begrijp. Vanwege de huidige manier waarop zo'n systeem op mijn werk is opgezet komen we dat nooit tegen (en dan bedoel ik: De manier waarop 't nu bij ons draait is totaal niet logisch en zwaar onhandig).
Bedankt! Dat maakt 't voor mij tenminste duidelijk waarom het een probleem is, en in welk geval dat bijvoorbeeld zou optreden.

[Hipska]

.oisyn schreef op vrijdag 23 september 2016 @ 12:26:
Maar goed, voorbeeld. Stel je hebt een factuur gemodeleerd met de klasse Invoice. Je bedrijf dealt zowel met personen (Person) als met andere bedrijven (Company), en als je de factuur wilt emailen dan doe je dat voor beide entiteiten in een verschillende vorm. Goed, je klasse Invoice heeft dus een method sendEmail(), die is geöverload op Person en Company.

Welnu, je applicatie deed eerst niets met databases, maar nu wil je de boel virtualizeren naar een willekeurige database, en je gebruikt daarvoor een een of andere (eventueel zelfgeschreven) library die gebruik maakt van generics om proxy classes te maken voor je objecten. Laten we die voor de grap even Accessor<> noemen. Nu heb je dus een Accessor<Person> en een Accessor<Company>, maar nu kun je je sendEmail() ineens niet meer overloaden in Java want door type erasure zijn beide types eigenlijk gewoon dezelfde.

Ik ben nu geen JAVA programmeur en heb geen ervaring met generics, maar waarom zou je in dit geval niet een PersonAccessor en CompanyAccessor hebben die beiden afgeleid zijn van Accessor?

Shoot me als ik nu een hele domme vraag gesteld heb

[.oisyn]

Hipska schreef op vrijdag 23 september 2016 @ 12:45:
[...]


Ik ben nu geen JAVA programmeur en heb geen ervaring met generics, maar waarom zou je in dit geval niet een PersonAccessor en CompanyAccessor hebben die beiden afgeleid zijn van Accessor?

Ah ja, net zoals dat je OptionalString en een OptionalDate etc. maakt voor elke mogelijke Optional<T> die je wilt hebben



Accessor<T> is generiek, die werkt ongeacht het object waar hij toegang toe biedt. Die code schrijf je maar 1 keer, je gaat niet voor elke mogelijke Accessor<T> een klasse intypen . Dat is het hele doel van generics, generieke code en types schrijven.

[ Voor 6% gewijzigd door .oisyn op 23-09-2016 13:04 ]

[RayNbow]

.oisyn schreef op vrijdag 23 september 2016 @ 11:29:
[...]

Interesting read, maar er wordt niet echt een fair plaatje van C++ templates gegeven door met termen als loose typing te smijten .

Mijn ervaring met C++ is nog wat beperkt, maar ik begrijp zijn punt wel. Het gros van de typechecking wordt (zover ik begrijp) pas utigevoerd nadat een gehele template is ingevuld. De templates zelf zijn niet echt een onderdeel van het typesystem.

[.oisyn]

RayNbow schreef op vrijdag 23 september 2016 @ 13:17:
[...]

Mijn ervaring met C++ is nog wat beperkt, maar ik begrijp zijn punt wel. Het gros van de typechecking wordt (zover ik begrijp) pas utigevoerd nadat een gehele template is ingevuld.

Alleen voor dependent types. Voor de rest moet een template functie of class gewoon koek&ei zijn bij definitie. Je mag geen int bij een std::string optellen, ook niet in een template functie die nog niet geïnstantieerd is (en die int en std::string niet indirect via de template parameters zijn binnen komen rollen):

C++:

template<class T>
void Foo()
{
    std::string i("hoi");
    i += 5;
}

Deze template definitie is fout ongeacht ik Foo<> daadwerkelijk gebruik of niet.

Maar dan nog, die invulling komt uiteindelijk in dezelfde compilatiestap. Uiteindelijk is je template instantiatie gewoon strong typed tijdens compilatie.

Met concepts (nog niet in C++17 helaas) kun je de template types limiteren aan de hand van requirements. Ik weet even niet of dit ook betekent dat je geen acties mag doen op de template types die niet gespecificeerd zijn in de requirements van een concept.'

De templates zelf zijn niet echt een onderdeel van het typesystem.

De relevantie daarvan ontgaat me een beetje . Bij Foo<T> is 'Foo' idd geen type-id, maar eem template-id. Foo<T> voor een concrete T is het concrete type, en is een compleet ander type dan Foo<U> waarbij T != U. Is dat in .Net niet ook het geval? Mag je daar 'Foo' gebruiken als type?

[ Voor 24% gewijzigd door .oisyn op 23-09-2016 14:25 ]

[Firesphere]

gekkie schreef op donderdag 22 september 2016 @ 14:40:
[...]

Net zoals er een glijende schaal is van een generieke dicussie over een taal, naar persoonlijke feedback op persoonlijke keuzes bij persoonlijk werk.

Vuurbal leek in eerste instantie over het eerste te beginnen, ondertussen lijken we bij het laatste beland.

Bij een generieke discussie met kritiek lijkt het me toch niet zo gek dat als mensen:
- dat geheel op zich zelf en de keuzes die ze maken betrekken
- het dus als feedback zien
- en daar ook nog depressief van raken
dat mensen daar dan de feedback op geven dat dat wellicht in zich zelf niet zo'n handige keuze is ?

Geen van de opties. Ik wil alleen maar aanwijzen, dat er een gezwel in de community is die uitingen als "{Taal} is kut" bevorderd en er zelfs een engineers disease is ontstaan rondom dat topic. Denk na voor je iets stoms zegt.

[DevWouter]

.oisyn schreef op vrijdag 23 september 2016 @ 13:26:
[...]


Alleen voor dependent types. Voor de rest moet een template functie of class gewoon koek&ei zijn bij definitie. Je mag geen int bij een std::string optellen, ook niet in een template functie die nog niet geïnstantieerd is (en die int en std::string niet indirect via de template parameters zijn binnen komen rollen):

C++:

template<class T>
void Foo()
{
    std::string i("hoi");
    i += 5;
}

Deze template definitie is fout ongeacht ik Foo<> daadwerkelijk gebruik of niet.

Maar dan nog, die invulling komt uiteindelijk in dezelfde compilatiestap. Uiteindelijk is je template instantiatie gewoon strong typed tijdens compilatie.

Met concepts (nog niet in C++17 helaas) kun je de template types limiteren aan de hand van requirements. Ik weet even niet of dit ook betekent dat je geen acties mag doen op de template types die niet gespecificeerd zijn in de requirements van een concept.'


[...]

De relevantie daarvan ontgaat me een beetje . Bij Foo<T> is 'Foo' idd geen type-id, maar eem template-id. Foo<T> voor een concrete T is het concrete type, en is een compleet ander type dan Foo<U> waarbij T != U

Ik weet niet of ik blij moet zijn met concepts. Ik snap wat ze doen, maar ik vind de kracht van een template juist dat het niks anders is dan "laten we de typename vervangen door een echte type". Met concepts krijg ik toch het gevoel dat templates een soort generic wordt.

Sure, het verbeterd de veiligheid, maar als ik denk dat std::basic_string<float> een goed idee is sta dat dan gewoon toe.

Het liefst zou ik willen dat de compiler de optie heeft "Ignore concepts, let me assume I'm a pro while I'm not".

Vind het ook verschrikkelijk dat ik er niet fel voor ben terwijl ik juist geen enkel inhoudelijk argument kan bedenken waarom ik tegen zou kunnen zijn.

[ThomasG]

DevWouter schreef op vrijdag 23 september 2016 @ 14:01:
[...]


Ik weet niet of ik blij moet zijn met concepts. Ik snap wat ze doen, maar ik vind de kracht van een template juist dat het niks anders is dan "laten we de typename vervangen door een echte type". Met concepts krijg ik toch het gevoel dat templates een soort generic wordt.

Sure, het verbeterd de veiligheid, maar als ik denk dat std::basic_string<float> een goed idee is sta dat dan gewoon toe.

Het liefst zou ik willen dat de compiler de optie heeft "Ignore concepts, let me assume I'm a pro while I'm not".

Vind het ook verschrikkelijk dat ik er niet fel voor ben terwijl ik juist geen enkel inhoudelijk argument kan bedenken waarom ik tegen zou kunnen zijn.

Volgens mij is er nog steeds de mogelijkheid om templates op de "oude" manier te gebruiken. Het voegt enkel de mogelijkheid tot constraints toe. Dat kan nu ook al, maar op een (omslachtige) work-around manier (bijvoorbeeld met enable_if, e.d.)

[Cornelisjuh]

Google maps API en identieke plaatsnamen

Weet nu niet of ik nu boos ben op Google of de vele noemers van identieke Nederlandse plaatsnamen

[.oisyn]

DevWouter schreef op vrijdag 23 september 2016 @ 14:01:
[...]


Ik weet niet of ik blij moet zijn met concepts.

Ik weet het wel; je moet er blij mee zijn

Ik snap wat ze doen, maar ik vind de kracht van een template juist dat het niks anders is dan "laten we de typename vervangen door een echte type". Met concepts krijg ik toch het gevoel dat templates een soort generic wordt.

Niet waar. Het blijven templates, maar het geeft de schrijver van de template de mogelijkheid om vooraf te specificeren waar een type aan moet voldoen. Bij een juiste specificatie levert dat een exact identiek gebruik op, maar resulteert het wel in betere errormeldingen. Plus, je kunt met concepts veel makkelijker overloaden en loop je niet te prutsen met SFINAE.

Sure, het verbeterd de veiligheid

Dat is nou precies wat het niet doet.

maar als ik denk dat std::basic_string<float> een goed idee is sta dat dan gewoon toe.

Ik zie niet in waarom dat met concepts niet meer zou mogen. Bij een juiste opzet zijn de constraints precies strict genoeg om de gevallen af te dekken die compile errors opleveren. In het geval van basic_string<float> betekent het waarschijnlijk zoiets als dat er een char_traits<float> moet bestaan met de juiste typedefs en support functies. Logisch, want anders compilet het sowieso niet.

Kijk, je kunt natuurlijk altijd strictere requirements specificeren dan nodig. Bijvoorbeeld dat de types optelbaar moet zijn voor een std::vector. Maar dat slaat natuurlijk nergens op. Voor een vector moeten ze gewoon copy constructable danwel move constructable zijn, en mag de dtor niet throwen. In de praktijk krijg je momenteel gewoon een cryptische error ergens in de implementatie van std::vector als je type daar niet aan voldoet (nou ja, non throwing dtor zou niet in een error resulteren dan, maar als je dat hebt verdien je sowieso stokslagen)

[ Voor 16% gewijzigd door .oisyn op 23-09-2016 14:23 ]

[alienfruit]

Hitler en Docker, zucht. Zulke filmpjes beginnen wel oud te worden. Docker vind ik eigenlijk best wel een interessant idee.

[gekkie]

Firesphere schreef op vrijdag 23 september 2016 @ 13:47:
[...]
Geen van de opties. Ik wil alleen maar aanwijzen, dat er een gezwel in de community is die uitingen als "{Taal} is kut" bevorderd en er zelfs een engineers disease is ontstaan rondom dat topic. Denk na voor je iets stoms zegt.

Een gezwel maar liefst, daar worden zowel PHP als een kut inderdaad niet mooier van.

[DevWouter]

.oisyn schreef op vrijdag 23 september 2016 @ 14:18:
Kijk, je kunt natuurlijk altijd strictere requirements specificeren dan nodig. Bijvoorbeeld dat de types optelbaar moet zijn voor een std::vector. Maar dat slaat natuurlijk nergens op. Voor een vector moeten ze gewoon copy constructable danwel move constructable zijn, en mag de dtor niet throwen.

Ah kijk, dat is dus mijn probleem. Ik ben bang dat er idioten zijn die meer afdichten dan nodig is. Probleem is dan ook niet concepts, maar die idioot.

Bedankt voor de verhelderende uitleg!

[ThomasG]

DevWouter schreef op vrijdag 23 september 2016 @ 14:31:
[...]


Ah kijk, dat is dus mijn probleem. Ik ben bang dat er idioten zijn die meer afdichten dan nodig is. Probleem is dan ook niet concepts, maar die idioot.

Bedankt voor de verhelderende uitleg!

Dat zal je altijd houden. Net zoals er libraries zijn die nog nooit van const gehoord hebben..

[DevWouter]

ThomasG schreef op vrijdag 23 september 2016 @ 14:33:
[...]
Dat zal je altijd houden. Net zoals er libraries zijn die nog nooit van const gehoord hebben..

Klopt, maar als we elke idioot verbieden om te programmeren dan hebben we zelf ook geen baan meer

Overigens heb ik ooit een heel verhaal gelezen over "waarom const evil is" en één voorbeeld is me altijd bijgebleven.

C++:

void proof_const_doesnt_work(const int& value) {
    int* pointer = &value;
    (*pointer) = 13; // And we have defeated const.
}

Was duidelijk iemand die het niet helemaal begreep

[.oisyn]

ThomasG schreef op vrijdag 23 september 2016 @ 14:33:
[...]
Dat zal je altijd houden. Net zoals er libraries zijn die nog nooit van const gehoord hebben..

Ik herinner me een Xbox 1 SDK API call die iets als een array van friends verwachtte. Iets als:

C++:

XRESULT XQueryFriendStatusses(const XPERSONA** ppFriends, int numFriends);

En dan geconfronteerd worden met een foutmelding nadat je die array op de stack hebt aangemaakt aan de hand van non-const XPERSONA pointers

Pop-quiz: waarom is een T** niet impliciet converteerbaar naar een const T**?
(dit haakt ook wel een beetje in op de covariant array discussie van gisteren )

[ Voor 6% gewijzigd door .oisyn op 23-09-2016 14:54 ]

[F.West98]

RayNbow schreef op vrijdag 23 september 2016 @ 06:44:
[...]

Geen .OfType<T>()?

[...]

Maar wat doe je vervolgens met het resultaat waarin T een rol speelt? Blijkbaar is someList een List<S> where T : S of misschien zelfs een niet-generieke List. Je kunt je dan afvragen waarom someList niet beter een List<T> had kunnen zijn.

Het ging hier om een lijst met alle elementen S die zichtbaar op het scherm zijn, en on click wilde ik natuurlijk weten welke aangeklikt was, alleen wilde ik dan alleen maar elementen T terug (T:S) omdat die alleen maar klikbaar zijn. Meerdere lists zou de draw logica (en order) alleen maar ingewikkelder maken in dit geval.

Merethil schreef op vrijdag 23 september 2016 @ 07:18:

[...]


Blijkbaar kan 't toch wel:

Java:

private <T> List<T> getTypeListFromList(List<?> list, Class<T> type) {
    List<T> newList = new ArrayList<>();
        
    newList = list.stream().filter(type::isInstance).map(s -> (T) s).collect(Collectors.toList());
        
    return newList;
}

Op zich vind ik het niet heel netjes, vooral omdat je een cast doet, maar die kan je prima doen omdat je al gefilterd hebt.
Nadat ik deze function probeerde met mijn lijst van foods en als Class<T> banana meegegeven heb, krijg ik inderdaad een lijst van Banana's terug.

Maar dan heb je dus wel de extra type parameter die je in C# dus niet nodig hebt omdat Java aan type erasure doet. Dat was het punt

[Hipska]

.oisyn schreef op vrijdag 23 september 2016 @ 13:02:
[...]


Ah ja, net zoals dat je OptionalString en een OptionalDate etc. maakt voor elke mogelijke Optional<T> die je wilt hebben

[afbeelding]

Accessor<T> is generiek, die werkt ongeacht het object waar hij toegang toe biedt. Die code schrijf je maar 1 keer, je gaat niet voor elke mogelijke Accessor<T> een klasse intypen . Dat is het hele doel van generics, generieke code en types schrijven.

Okee, ik vermoedde het al, het was dus een domme vraag

[Merethil]

F.West98 schreef op vrijdag 23 september 2016 @ 15:25:
[...]

Het ging hier om een lijst met alle elementen S die zichtbaar op het scherm zijn, en on click wilde ik natuurlijk weten welke aangeklikt was, alleen wilde ik dan alleen maar elementen T terug (T:S) omdat die alleen maar klikbaar zijn. Meerdere lists zou de draw logica (en order) alleen maar ingewikkelder maken in dit geval.


[...]

Maar dan heb je dus wel de extra type parameter die je in C# dus niet nodig hebt omdat Java aan type erasure doet. Dat was het punt

Oh dan las ik je opmerking verkeerd, ik bouwde alleen jouw voorbeeld na

[Robicide]

Zo, na twee dagen installeren en configureren en debuggen en nog meer configureren en nog wat installeren heb ik dan ein-de-lijk een Mac Mini als iOS build server voor Visual Studio + Xamarin weten in te richten.

iOS emulator werkt ook prima op de Mac Mini. iOS Simulator for Windows blijft echter hangen op "Connecting to Mac"

Gelukkig is het weekend. Manmanman, Xamarin.

[.oisyn]

.oisyn schreef op vrijdag 23 september 2016 @ 14:53:
Pop-quiz: waarom is een T** niet impliciet converteerbaar naar een const T**?
(dit haakt ook wel een beetje in op de covariant array discussie van gisteren )

Niemand?

[RagingPenguin]

.oisyn schreef op vrijdag 23 september 2016 @ 17:33:
[...]


Niemand?

Heey, we zijn hier voor gratiz popcorn, niet voor moeilijke vragen

[ThomasG]

.oisyn schreef op vrijdag 23 september 2016 @ 17:33:
[...]

Niemand?

Omdat het onveilig is, en daarmee problemen creëert/kunt creëren. Stel je hebt de code:

C++:

Foo * pFoo;
Foo const ** ppFoo = &pFoo;

Dan kun je door *ppFoo te laten wijzen naar een const Foo, een non-const Foo bewerken via pFoo. Nu zou je regel 2 kunnen wijzigen door een cast toe te voegen, bijvoorbeeld:

C++:

Foo const ** ppFoo = (Foo const **) &pFoo;

Waardoor de compiler het wel slikt. Maar daardoor by-pass je eigenlijk het probleem. De werkelijke oplossing zou zijn door *pFoo const te maken, met:

C++:

Foo const * const * ppFoo = &pFoo;

Wat wel impliciet kan, omdat je de const qualifier niet kunt verliezen.

* Ja, ik doe mijn const qualifier altijd rechts, zodat het consistent is met de situaties waar het niet links kan.

[Ryur]

Robicide schreef op vrijdag 23 september 2016 @ 17:12:
Zo, na twee dagen installeren en configureren en debuggen en nog meer configureren en nog wat installeren heb ik dan ein-de-lijk een Mac Mini als iOS build server voor Visual Studio + Xamarin weten in te richten.

iOS emulator werkt ook prima op de Mac Mini. iOS Simulator for Windows blijft echter hangen op "Connecting to Mac"

Gelukkig is het weekend. Manmanman, Xamarin.

Ik werk nu 2 jaar met Xamarin, nergens problemen gehad met een MacMini & Visual Studio. Ben benieuwd waar jij dan tegenaan bent gelopen? Toevallig ben ik nu meerdere collega's aan het meenemen met Xamarin, dus wie weet of zij die problemen ook tegenkomen.

De iOS Simulator for Windows is nog in Beta, ik werk er zelf nog niet mee (om beta & deadlines van het huidige project, geen tijd om me erin te verdiepen). Momenteel werk ik gewoon met de simulator op mijn Mac.

Voor de rest: Xamarin

[Caelorum]

Robicide schreef op vrijdag 23 september 2016 @ 17:12:
[...]
Gelukkig is het weekend. Manmanman, Xamarin.

Probeer het eens met Cordova en VS studio. Elke maand mochten wij weer opnieuw beginnen met uitzoeken waarom we niet meer konden builden. Elke maand minstens 1 dag verspilt. Ben blij dat we nu naar xamarin overstappen. Het kan nooit zo erg zijn als dat.

[.oisyn]

ThomasG schreef op vrijdag 23 september 2016 @ 19:18:

Punten voor ThomasG

[RayNbow]

F.West98 schreef op vrijdag 23 september 2016 @ 15:25:
[...]

Het ging hier om een lijst met alle elementen S die zichtbaar op het scherm zijn, en on click wilde ik natuurlijk weten welke aangeklikt was, alleen wilde ik dan alleen maar elementen T terug (T:S) omdat die alleen maar klikbaar zijn. Meerdere lists zou de draw logica (en order) alleen maar ingewikkelder maken in dit geval.

Maar zijn S en T hier generieke type parameters of concrete types?

.oisyn schreef op vrijdag 23 september 2016 @ 13:26:
[...]


Alleen voor dependent types. Voor de rest moet een template functie of class gewoon koek&ei zijn bij definitie. Je mag geen int bij een std::string optellen, ook niet in een template functie die nog niet geïnstantieerd is (en die int en std::string niet indirect via de template parameters zijn binnen komen rollen):

C++:

template<class T>
void Foo()
{
    std::string i("hoi");
    i += 5;
}

Deze template definitie is fout ongeacht ik Foo<> daadwerkelijk gebruik of niet.

Maar dan nog, die invulling komt uiteindelijk in dezelfde compilatiestap. Uiteindelijk is je template instantiatie gewoon strong typed tijdens compilatie.

Met concepts (nog niet in C++17 helaas) kun je de template types limiteren aan de hand van requirements. Ik weet even niet of dit ook betekent dat je geen acties mag doen op de template types die niet gespecificeerd zijn in de requirements van een concept.'

Ik denk dat ik probeer te zeggen dat C++ templates werken door te kijken of na invulling alles klopt i.p.v. bijv. in Java of C# alleen naar respectievelijk de bounds of type parameter constraints te kijken. Daardoor komt het wat losjes over.

(Uiteraard is het niet loosely typed als in de betekenis van iets als wat PHP hanteert.)

Hetzelfde heb ik trouwens met de LINQ-syntax in C# (en VB). Dat voelt toch nog een beetje als een hack. Eerst wordt alles omgeschreven naar method calls en wordt er adhoc gekeken of dan alles nog klopt.

(Maar ja, het achterliggende idee van LINQ is niet in het typesystem van C# te vatten.)

[...]

De relevantie daarvan ontgaat me een beetje . Bij Foo<T> is 'Foo' idd geen type-id, maar eem template-id. Foo<T> voor een concrete T is het concrete type, en is een compleet ander type dan Foo<U> waarbij T != U. Is dat in .Net niet ook het geval? Mag je daar 'Foo' gebruiken als type?

Nee, niet zomaar. Foo los is een non-generic Foo type (als die bestaat). Je kan in C# wel een unbound generic type gebruiken, maar dan alleen in de typeof constructie, bijv. typeof(Func<,,>).

Over het idee van "templates als onderdeel van het typesystem", hierbij moet ik vooral denken aan Haskell. Stel dat je het volgende hebt:

Haskell:

-- Maybe is vergelijkbaar met Optional in andere talen:
data Maybe a = Just a
             | Nothing

In Haskell is iets als Maybe Int een type en is Maybe los een type constructor. Nu kun je Maybe niet los gebruiken, maar wel in type-expressies op een vergelijkbare manier als template template parameters in C++.

.oisyn schreef op vrijdag 23 september 2016 @ 17:33:
[...]


Niemand?

De eerste drempel is het parsen van het type (of cdecl.org gebruiken).

[F.West98]

RayNbow schreef op vrijdag 23 september 2016 @ 20:47:
[...]

Maar zijn S en T hier generieke type parameters of concrete types?

Type parameter T en concreet type S.
In de praktijk: GraphElement (S) en bijvoorbeeld GraphVertex (T).

[Firesphere]

gekkie schreef op vrijdag 23 september 2016 @ 14:31:
[...]

Een gezwel maar liefst, daar worden zowel PHP als een kut inderdaad niet mooier van.

"Denk na voor je iets stoms zegt"

[gekkie]

Firesphere schreef op zondag 25 september 2016 @ 07:32:
[...]

"Denk na voor je iets stoms zegt"

Iets met potten ketels verwijten en zwart zien

[Firesphere]

gekkie schreef op zondag 25 september 2016 @ 10:13:
[...]

Iets met potten ketels verwijten en zwart zien

Aangezien ik al meerdere keren heb toegegeven aan dergelijke praktijken ook zelf te hebben meegedaan, gaarne elaboreer.

Ik kan wel toevoegen dat ik zwaar teleurgesteld ben in jullie houding, maar goed. Dat kan ik helaas niet veranderen en jullie zijn te koppig om zelf na te denken.

[.oisyn]

Of, we delen je mening gewoon niet.

[Firesphere]

.oisyn schreef op zondag 25 september 2016 @ 11:57:
Of, we delen je mening gewoon niet.

Nah, weinig "mening". De implicite cultuur die er heerst heeft weinig met mening te maken.

Het doorbreken van die impliciete cultuur is blijkbaar te veel gevraagd.

[ Voor 13% gewijzigd door Firesphere op 25-09-2016 12:09 ]