[C#] Overloading operators

woensdag 20 juni 2007 12:28

Admin Devschuur®

^ Romeinse Ⅲ ja!

Of wacht op de volgende versie van C#, welke inline SQL ondersteunt

[ Voor 34% gewijzigd door RobIII op 20-06-2007 12:32 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

woensdag 20 juni 2007 13:35

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op woensdag 20 juni 2007 @ 12:13:
C#:
1
2
ProductClass a = new ProductClass();
a.ProductID < 5;
En ik heb het idee dat dit niet kan. Wellicht dat er een GoTTer is die me kan vertellen hoe dit wel kan en of het uberhaupt kan

Waarom heb je dat idee? Ik ben geen C# guru, maar aangezien het gewoon van de C en C++ syntax leent, is een full expression ook gewoon een geldige statement. x() is een full expression, ookal returnt x eigenlijk een waarde waar je niets mee doet. Waarom mag dat dan niet met x + 4 of x < 5 oid? Heb je het geprobeerd? Wat zegt de compiler?

[.edit: het mag idd niet, wat suf. Uit de C# specificatie:

expression-statement:
statement-expression ;

statement-expression:
invocation-expression
object-creation-expression
assignment
post-increment-expression
post-decrement-expression
pre-increment-expression
pre-decrement-expression

Not all expressions are permitted as statements. In particular, expressions such as x + y and x == 1 that merely compute a value (which will be discarded), are not permitted as statements.

Je zou er evt. een dummy functie omheen kunnen zetten

C#:

1 2	where (a.propertyA > 4); where (a.probertyB == 5);

etc

]

lier schreef op woensdag 20 juni 2007 @ 12:23:
Dacht dat het ranzig was wat je wilde, maar dit is echt bizar...

Waarom pas je niet gewoon een enumerator toe (GreaterThan, SmallerThan, GreaterOrEqual, enz...)
Dan je kan je op een "nette" manier je SQL statement in de juiste laag opbouwen.

Dat zijn manier niet gebruikelijk is in C#, wil nog niet meteen zeggen dat het niet netjes is. Overloaded operators zijn een mooie manier om iets op een bepaalde manier uit te drukken als een taal-in-een-taal. In C++ zie je dit wel vaker, kijk bijvoorbeeld maar eens naar boost::lambda of boost::spirit.

[ Voor 52% gewijzigd door .oisyn op 20-06-2007 12:40 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 20 juni 2007 13:36

.oisyn schreef op woensdag 20 juni 2007 @ 12:28:
Dat zijn manier niet gebruikelijk is in C#, wil nog niet meteen zeggen dat het niet netjes is.

Komop zeg. Een > operator die helemaal geen vergelijking doet maar in een class een flag zet zodat je op het moment dat SQL gegenereerd wordt pas die informatie gebruikt, dat is, zoals al gezegd is, niet 'smerig' maar gewoon compleet bizar. D'r is no way dat dat van een collega geaccepteerd zou worden.

Operator overloading is sowieso alleen nuttig als je ze gebruikt voor dingen die 'logisch' zijn. Iemand die die code moet gaan snappen raakt compleet de weg kwijt.

[ Voor 14% gewijzigd door Hydra op 20-06-2007 13:36 ]

https://niels.nu

Acties:

Woy

Moderator Devschuur®

Als ik jou was zou ik eens naar c# 3.0 kijken met LINQ. Daar zitten wat taalfeatures in waar je denk wel mee kan wat je wilt.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

woensdag 20 juni 2007 13:43

Acties:

woensdag 20 juni 2007 14:06

Moderator Devschuur®

Demotivational Speaker

Hydra schreef op woensdag 20 juni 2007 @ 13:35:

Komop zeg. Een > operator die helemaal geen vergelijking doet maar in een class een flag zet zodat je op het moment dat SQL gegenereerd wordt pas die informatie gebruikt, dat is, zoals al gezegd is, niet 'smerig' maar gewoon compleet bizar. D'r is no way dat dat van een collega geaccepteerd zou worden.

Niet in jouw kringen misschien. Gelukkig is jouw mening niet wet

. Bovendien doet die expressie wel een vergelijking, alleen niet op dat moment maar bij het uitvoeren van het SQL statement.

Kijk, het gebruik van een dergelijke klasse is redelijk confined. Je zult 'm niet verspreid zien staan over je project, en bovendien ga je nooit zinnige waarden aan dergelijke properties toekennen. Hij wordt gebruikt om op een intuitieve manier queries te bouwen zodat die later uitgevoerd kunnen worden.

boost::lambda is hier ook een mooi voorbeeld van. Die gebruikt template en operator magic om lambda expressies te bouwen, zodat je die kunt voeren aan iets dat een functor verwacht. Zoals bijvoorbeeld:

C++:

1
2
3

std::vector<int> v(10);
std::for_each(v.begin(), v.end(), std::cout << _1 << std::endl);
std::sort(v.begin(), v.end(), _1 > _2);

_1 en _2 zijn objecten die dienen als placeholders voor de argumenten. De operatoren op die objecten zijn geoverload om wat de gebruiker wil te vertalen naar code die op een later moment geevalueerd kan worden. Wat de topicstarter hier wil is feitelijk niet heel anders, behalve dat C# natuurlijk minder features heeft om dit mooi te implementeren. Het is gewoon een vorm van meta programming.

Wat bizar is, is een ++ operator implementeren zodat ie er 1 van af trekt, of <= te implementeren die iets met 5 vermenigvuldigt. De betekenis van de operators zoals de topicstarter die wilt implementeren verandert niet, dus zo heel bizar is het niet.

[ Voor 66% gewijzigd door .oisyn op 20-06-2007 13:55 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 20 juni 2007 14:15

.oisyn schreef op woensdag 20 juni 2007 @ 13:43:
Niet in jouw kringen misschien. Gelukkig is jouw mening niet wet . Bovendien doet die expressie wel een vergelijking, alleen niet op dat moment maar bij het uitvoeren van het SQL statement.

Een X > Y vergelijking levert een boolean op. Klaar. Het is gewoon een wiskundige vergelijking, is X groter dan Y, ja of nee. Als je hier een andere betekenis aan toe gaat wijzen (X > Y: "sla in object O op dat als SQL gegenereerd moet worden alleen rows geretourneerd moeten worden waarbij X groter is dan Y), ben je echt bizar bezig. Ieder normaal persoon zou hiervoor met parameters werken. Heck, .Net heeft dat gewoon in de API INGEBOUWD zitten.

En wat betreft "niet in jouw kringen": ik ben technisch consultant voor een technologie bedrijf en begeleidt grote implementaties bij middelgrote tot hele grote bedrijven. Deze mensen betalen 'vrij veel' geld (tonnen tot miljoenen) voor goede software. Een programmeur die dit soort absurde dingen zou verzinnen zou bij eenieder van die bedrijven 'vriendelijk doch dringend' verzocht worden om zich aan de gangbare conventies te houden. Het idee van samenwerken is namelijk dat je niet je eigen stukje domein toeeigent en dat zo obscuur mogelijk maakt. Als ik iets dergelijks voor een klant zou maken (en reken maar dat code die ik schrijf gereviewed wordt) zouden ze mijn bedrijf gewoon vragen om een ander, omdat ik bagger oplever.

Dus hou je "in jouw kringen" alsjeblieft voor je. Voorzover ik weet knutsel jij aan een 3D engine en wat tools bij een gamedesign bedrijfje. Dus laten we onze piemels even in onze broek houden, en inhoudelijk discussieren.

Kijk, het gebruik van een dergelijke klasse is redelijk confined. Je zult 'm niet verspreid zien staan over je project, en bovendien ga je nooit zinnige waarden aan dergelijke properties toekennen. Hij wordt gebruikt om op een intuitieve manier queries te bouwen zodat die later uitgevoerd kunnen worden.

Eenn compleet nonargument, maar je brengt me wel op een idee. Misschien moeten we overwegen dit forum te scheiden in "Lekker aankutten" en "Serieus development". Dan weet ik wel welke van de twee ik uit m'n index ga gooien.

https://niels.nu

Acties:

woensdag 20 juni 2007 14:20

Admin Devschuur®

^ Romeinse Ⅲ ja!

Modbreak:En nou wil ik hier geen op-de-man-geflame meer zien. Hou het gewoon netjes, gezellig en beschaafd

Meningen kunnen prima verschillen, maar dat kan ook op normale manier besproken worden; dit gaat nergens (meer) over.

[ Voor 36% gewijzigd door RobIII op 20-06-2007 14:17 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

woensdag 20 juni 2007 14:33

Moderator Devschuur®

Demotivational Speaker

Hydra schreef op woensdag 20 juni 2007 @ 14:06:

Een X > Y vergelijking levert een boolean op. Klaar. Het is gewoon een wiskundige vergelijking, is X groter dan Y, ja of nee. Als je hier een andere betekenis aan toe gaat wijzen (X > Y: "sla in object O op dat als SQL gegenereerd moet worden alleen rows geretourneerd moeten worden waarbij X groter is dan Y), ben je echt bizar bezig. Ieder normaal persoon zou hiervoor met parameters werken. Heck, .Net heeft dat gewoon in de API INGEBOUWD zitten.

Die plaat voor je harses is wel heel erg dik he

En wat betreft "niet in jouw kringen": ik ben technisch consultant voor een technologie bedrijf en begeleidt grote implementaties bij middelgrote tot hele grote bedrijven. Deze mensen betalen 'vrij veel' geld (tonnen tot miljoenen) voor goede software.

Dus hou je "in jouw kringen" alsjeblieft voor je. Voorzover ik weet knutsel jij aan een 3D engine en wat tools bij een gamedesign bedrijfje. Dus laten we onze piemels even in onze broek houden, en inhoudelijk discussieren.

Iets met pot verwijt de ketel. Grappig dat je meteen mijn "bedrijfje" erbij betrekt, terwijl ik dat helemaal niet heb gedaan, noch jouw bedrijf erbij betrek. Als jij zegt dat *alle* collega's het niet accepteren, dan ben ik van mening dat je kijk op de zaak zeer bekrompen is en dat je verder moet kijken dan je neus lang is. Waar je dan vandaan komt kan mij weinig schelen. Ook is het niet zo dat wij dit soort dingen hier op het werk doen, we doen namelijk niets met meta programming.

Jij sinueert hiermee echter wel dat de mensen van boost en het C++ committee prutsers zijn. Sorry, maar dat wil er bij mij niet in, en ik denk bij jouw klanten net zo min.

Dus, doe niet zo triest, en denk niet elke keer dat wij een meningsverschil hebben dat ik een prutser ben en dat jij het allemaal veel beter werkt. Want de werkelijkheid is dat je gewoon een dikke vette plaat voor je harses hebt en totaal niet open staat voor andere ideeën of visies. Ik zeg niet dat je het ermee eens hoeft te zijn, maar ga niet dingen lopen prediken alsof het een fucking religie is.

Ik ga er maar even van uit dat je de modbreak nog niet gezien had toen je begon met typen...

[ Voor 5% gewijzigd door RobIII op 20-06-2007 14:25 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 20 juni 2007 14:38

Moderator Devschuur®

Demotivational Speaker

Sorry RobIII, had je modbreak idd nog niet gezien.

Hydra, had je trouwens nog een inhoudelijke opmerking, of blijft het bij "het is bizar" en "compleet nonargument" zonder argumentatie? Ik was de discussie namelijk weldegelijk inhoudelijk aangegaan, alleen een inhoudelijk antwoord is tot nu toe nog ver te zoeken

[ Voor 31% gewijzigd door .oisyn op 20-06-2007 14:41 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

left part of the evil twins

Hydra schreef op woensdag 20 juni 2007 @ 14:06:
[...]

Een X > Y vergelijking levert een boolean op. Klaar. Het is gewoon een wiskundige vergelijking, is X groter dan Y, ja of nee. Als je hier een andere betekenis aan toe gaat wijzen (X > Y: "sla in object O op dat als SQL gegenereerd moet worden alleen rows geretourneerd moeten worden waarbij X groter is dan Y)

Lees jij HTML ook als "kleiner dan html groter dan kleiner dan body groter dan kleiner dan title paginatitel groter dan"? En als er iemand naar een menuoptie verwijst als "Tools -> Options" ga je ook mekkeren dat er helemaal geen wiskundige relatie is tussen de twee operands?

Er zijn miljoenen plekken op te noemen waar de scherpe haak naar rechts anders wordt geinterpreteerd dan "is links groter dan rechts?" Je spreidt hier een kortzichtigheid tentoon die exemplarisch is voor onervaren developers met weinig echte praktijkervaring.

Syntax is een kwestie van conventies, die net zo goed binnen je team afgesproken kunnen worden, als binnen een vakgebied, waarbij wiskunde slechts een van de duizenden is.

Eenn compleet nonargument, maar je brengt me wel op een idee. Misschien moeten we overwegen dit forum te scheiden in "Lekker aankutten" en "Serieus development". Dan weet ik wel welke van de twee ik uit m'n index ga gooien.

Kunnen we dan meteen een toegangstest op de tweede zetten?

[ Voor 6% gewijzigd door curry684 op 20-06-2007 14:39 ]

woensdag 20 juni 2007 14:44

Acties:

Glimi

Designer Drugs

Ik vind er niets raars aan, ik doe niet anders in Haskell en met Stratego. Je probeert gewoon een SQL domain specific extension te maken in je general purpose taal om de boel wat compacter en helderder te kunnen formuleren. Helaas moet je denk ik wel concluderen dat C# in de huidige versie (3.0 even geen zicht op) daar gewoon geen features voor aanbied, waardoor je misschien beter een pre-processor kunt gaan gebruiken mocht je het toch heel graag willen.

@.oisyn 't is wel ff wennen voor me die syntax van lambda's zo

woensdag 20 juni 2007 14:47

Acties:

woensdag 20 juni 2007 14:48

Moderator Devschuur®

Demotivational Speaker

curry684 schreef op woensdag 20 juni 2007 @ 14:38:
Syntax is een kwestie van conventies, die net zo goed binnen je team afgesproken kunnen worden, als binnen een vakgebied, waarbij wiskunde slechts een van de duizenden is.

Well put, en dit is dan ook meteen de kern van de zaak. Ik zie niet wat het probleem is als je hier van tevoren duidelijke afspraken over maakt en alles goed documenteert. Als je je alleen maar vasthoudt aan wat je geleerd hebt en compleet niet open staat voor andere dingen schiet je je zelf uiteindelijk alleen maar in de voet, imho.

.edit: GLIMI!!! Long time no see, welcome back!

Glimi schreef op woensdag 20 juni 2007 @ 14:44:
@.oisyn 't is wel ff wennen voor me die syntax van lambda's zo

Ja je moet toch wat als de taal zelf z'n tekortkomingen heeft he

. Gelukkig zijn lambda expressies als first class citizens een active topic binnen C++, en zit het hopelijk gewoon in de volgende revisie (gepland voor 2009, weliswaar

)

[ Voor 30% gewijzigd door .oisyn op 20-06-2007 14:50 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

left part of the evil twins

offtopic:
GLIEMPOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!11111111111

woensdag 20 juni 2007 15:05

Acties:

d00d

geen matches

Ik kan je niet helpen met het probleem maar ik vind het wel grappig dat C# in de volgende release de => operator gebruikt voor lambda expressies.

Als Anders Hejlsberg het mag doen, dan mag jij het ook van mij, hoewel je mijn menig eigenlijk met een korreltje zout moet nemen want ik werk niet bij een groot bedrijf

42.7 percent of all statistics are made up on the spot.

woensdag 20 juni 2007 15:07

Acties:

sirdupre

Hydra schreef op woensdag 20 juni 2007 @ 14:06:
Een X > Y vergelijking levert een boolean op. Klaar. Het is gewoon een wiskundige vergelijking, is X groter dan Y, ja of nee. Als je hier een andere betekenis aan toe gaat wijzen (X > Y: "sla in object O op dat als SQL gegenereerd moet worden alleen rows geretourneerd moeten worden waarbij X groter is dan Y), ben je echt bizar bezig. Ieder normaal persoon zou hiervoor met parameters werken. Heck, .Net heeft dat gewoon in de API INGEBOUWD zitten.

Volgens mij sluit je dan in principe het gebruik van DSL's en Syntactische Suiker uit. Persoonlijk vind ik het toch echt mooier om iets als query.setWhere(person.age > 18 && person.city == Utrecht) te schrijven dan query.setWhere(new AndCondition(new GTCondition(person.age,18),new EQCondition(person.city,Utrecht))) te schrijven, al is het maar om de belachelijke hoeveelheid haakjes die je ermee voorkomt. Als je vervolgens met commentaar duidelijk beschrijft dat je hier SQL queries bouwt met een DSL, denk ik dat er geen programmeur is met een beetje verstand van dit soort zaken die het gruwelijk lelijk zal noemen, of er geen snars van zal begrijpen.

woensdag 20 juni 2007 15:10

Acties:

voodooless

Sound is no voodoo!

C#:

1	a.ProductID < 5

Wil je die operator überhaupt overloaden, zou je dat in dit geval in dat ProductID moeten doen, en niet in het object a!

Do diamonds shine on the dark side of the moon :?

woensdag 20 juni 2007 15:12

Acties:

Zr40

Moderator General Chat

heeft native IPv6

Wat je wel zou kunnen doen, is de betreffende operators implementeren met een niet-bool return type. De expressie 'person.age > 18' geeft dan bijvoorbeeld een WhereClause object terug, die je aan setWhere() kan meegeven.

[ Voor 3% gewijzigd door Zr40 op 20-06-2007 15:12 ]

woensdag 20 juni 2007 15:31

Acties:

woensdag 20 juni 2007 15:35

sirdupre schreef op woensdag 20 juni 2007 @ 15:07:
[...]

Volgens mij sluit je dan in principe het gebruik van DSL's en Syntactische Suiker uit. Persoonlijk vind ik het toch echt mooier om iets als query.setWhere(person.age > 18 && person.city == Utrecht) te schrijven dan query.setWhere(new AndCondition(new GTCondition(person.age,18),new EQCondition(person.city,Utrecht))) te schrijven, al is het maar om de belachelijke hoeveelheid haakjes die je ermee voorkomt.

Je hebt hier gelijk, maar in deze context gebruik je de > operator ook waarvoor hij bedoeld is; als je daarentegen de operator gaat gebruiken om een waarde te zetten ipv een conditie te evalueren is het niet meer "bizar" zoals Hydra vermeld, maar rondweg not done.

Operatoren overriden en hun semantiek compleet veranderen, dat is, plots geen boolean waarde meer returnen (wat niet kan, maar kom) maar enkel functioneren als een setter, is not done, gebruik de dingen waar ze voor dienen. Schrijf dan ook een setter.

Dat allemaal buiten beschouwing, als je dan toch per se nood hebt aan fishy oplossingen als de gevraagde, kan je beter je design compleet herbekijken.

Alex Vanden Abeele

Acties:

woensdag 20 juni 2007 15:35

Moderator Devschuur®

Demotivational Speaker

al3x schreef op woensdag 20 juni 2007 @ 15:31:
[...]

Je hebt hier gelijk, maar in deze context gebruik je de > operator ook waarvoor hij bedoeld is;

Ik denk dat iedereen in de topic er wel mee eens is dat het op z'n zachtst gezegd onhandig is om de operator op een andere manier te overloaden

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 20 juni 2007 15:47

.oisyn schreef op woensdag 20 juni 2007 @ 14:33:
Hydra, had je trouwens nog een inhoudelijke opmerking, of blijft het bij "het is bizar" en "compleet nonargument" zonder argumentatie? Ik was de discussie namelijk weldegelijk inhoudelijk aangegaan, alleen een inhoudelijk antwoord is tot nu toe nog ver te zoeken

Aangezien je alleen ingaat op de 'plaat voor m'n kop' en je vorige betoog begint met "gelukkig is jouw mening niet wet" vermoed ik dat wij geen discussie op inhoud gaan voeren met z'n tweeen. Wat ik wel even wil benadrukken is dat ik met het verhaal waar jij nogal selectief op reageer wil stellen dat ik vind dat een programmeur die op eigen houtje dit soort dingen in gaat bouwen een slechte programmeur is, simpelweg omdat de door de TS voorgestelde toepassing niet logisch is en de gemiddelde programmeur toch redelijk logisch denkt en als hij een stuk code leest ervanuitgaat dat a.ProductId < 5 een vergelijking is. Dat jij vindt dat er niks inhoudelijks is aan mijn reactie; tja. So be it

curry684 schreef op woensdag 20 juni 2007 @ 14:38:
Lees jij HTML ook als "kleiner dan html groter dan kleiner dan body groter dan kleiner dan title paginatitel groter dan"? En als er iemand naar een menuoptie verwijst als "Tools -> Options" ga je ook mekkeren dat er helemaal geen wiskundige relatie is tussen de twee operands?

Dit topic gaat over C# (en aanverwante talen), niet over HTML of een menu in een IDE.

Syntax is een kwestie van conventies, die net zo goed binnen je team afgesproken kunnen worden, als binnen een vakgebied, waarbij wiskunde slechts een van de duizenden is.

Binnen een team afspraken maken is natuurlijk compleet iets anders. Als de TS dit afgesproken heeft binnen z'n team, tja. Prima. Ik vind het in dit geval gruwelijk lelijk, maargoed, zijn feestje. Ik vermoed alleen dat dat hier absoluut niet het geval is.

d00d schreef op woensdag 20 juni 2007 @ 15:05:
Ik kan je niet helpen met het probleem maar ik vind het wel grappig dat C# in de volgende release de => operator gebruikt voor lambda expressies.

Ik vind dit compleet wat anders dan wat de TS probeert te bewerkstelligen. In de eerste plaats zijn anonymous methods en lambda expressions een standaard uitbreiding op een taal. Iedere developer die in zijn vakgebied up to date blijft snapt deze dingen.

sirdupre schreef op woensdag 20 juni 2007 @ 15:07:
Volgens mij sluit je dan in principe het gebruik van DSL's en Syntactische Suiker uit.

Oh nee, niet per definitie. Het gaat me er specifiek om dat hier logische operatoren worden overloaded om onlogische dingen te doen. Als hij iets had gedaan als een query.AddParameter(a.ProductId > 5) dan heb ik daar geen probleem mee omdat duidelijk is wat hier gebeurt; je voegt parameters to aan een query. De oplossing die de TS bedacht heeft is geen mooie creatieve oplossing die iedereen in 1 oogopslag snapt, het is, mijns inziens, gewoon een hack.

.oisyn schreef op woensdag 20 juni 2007 @ 15:35:
Ik denk dat iedereen in de topic er wel mee eens is dat het op z'n zachtst gezegd onhandig is om de operator op een andere manier te overloaden

Mag ik vragen waarom hij nu niet 'kortzichtig' is? Beetje vreemd dit

[ Voor 4% gewijzigd door Hydra op 20-06-2007 15:36 ]

https://niels.nu

Acties:

woensdag 20 juni 2007 15:57

Moderator Devschuur®

Demotivational Speaker

Hydra schreef op woensdag 20 juni 2007 @ 15:35:

Aangezien je alleen ingaat op de 'plaat voor m'n kop' en je vorige betoog begint met "gelukkig is jouw mening niet wet" vermoed ik dat wij geen discussie op inhoud gaan voeren met z'n tweeen.

No offense, maar als je überhaupt een discussie wilt voeren moet je wellicht niet claimen dat *niemand* in een professioneel bedrijf zoiets zou accepteren, want quite frankly denk ik niet dat jij daar zicht op hebt (net zo min als ik overigens, maar ik ga er dan ook niet zo glashard vanuit, en gezien de meningen van bepaalde prominenten, zoals een Doug Gregor en een Bjarne Stroustrup, klopt het gewoon niet). Enige nuance was op dat moment wel op z'n plaats, vandaar mijn wellicht bot overkomende (maar niet zo bedoelde btw, excuus als dat wel het geval was) reactie. Dat jij het meteen nodig vond om maar even te vertellen wat voor werk je doet, en onze discussie van onlangs over UML erbij te halen om mij en mij bedrijf onder resp. jou en de jouwe te zetten was onnodig, en simpelweg gewoon een beetje triest. Ik snap niet wat onze bedrijven hier ook maar enigszins mee te maken hebben.

Wat ik wel even wil benadrukken is dat ik met het verhaal waar jij nogal selectief op reageer wil stellen dat ik vind dat een programmeur die op eigen houtje dit soort dingen in gaat bouwen een slechte programmeur is

Dus even voor de goede orde, als je dit in een groot team zo afspreekt dan kan het wel, maar als je het in je eentje doet omdat je een hobbyist bent en daarom geen team achter je hebt staan, dan ben je een slechte programmeur? Juist als hobbyist kun je wat meer experimenteren en daarmee je eigen ervaring verrijken. Ik ben het er dan ook niet mee eens dat iemand dan meteen een slechte programmeur is.

Oh nee, niet per definitie. Het gaat me er specifiek om dat hier logische operatoren worden overloaded om onlogische dingen te doen. Als hij iets had gedaan als een query.AddParameter(a.ProductId > 5) dan heb ik daar geen probleem mee omdat duidelijk is wat hier gebeurt; je voegt parameters to aan een query. De oplossing die de TS bedacht heeft is geen mooie creatieve oplossing die iedereen in 1 oogopslag snapt, het is, mijns inziens, gewoon een hack.

Ik denk dat je je vergeet realiseren dat de topicstarter gewoon z'n probleem generiek probeert te beschrijven, en niet direct geïnteresseerd is in wat nou wel done en wat niet done is. Z'n probleembeschrijving is wat dat betreft vrij duidelijk, en met een antwoord op z'n vraag kan hij op weg om z'n implementatie wél leesbaar en intuitief te maken.

Mag ik vragen waarom hij nu niet 'kortzichtig' is? Beetje vreemd dit

euh

. Ik begrijp je niet.

[ Voor 6% gewijzigd door .oisyn op 20-06-2007 15:54 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

left part of the evil twins

al3x schreef op woensdag 20 juni 2007 @ 15:31:
[...]

Je hebt hier gelijk, maar in deze context gebruik je de > operator ook waarvoor hij bedoeld is; als je daarentegen de operator gaat gebruiken om een waarde te zetten ipv een conditie te evalueren is het niet meer "bizar" zoals Hydra vermeld, maar rondweg not done.

Operatoren overriden en hun semantiek compleet veranderen, dat is, plots geen boolean waarde meer returnen (wat niet kan, maar kom) maar enkel functioneren als een setter, is not done, gebruik de dingen waar ze voor dienen. Schrijf dan ook een setter.

Sja kijk ik vind groter-dan en kleiner-dan ook 2 van de minst aannemelijke kandidaten om te overloaden door hun overdadige wiskundige gebruik elders in de code, maar het punt is dat dat secundair is aan waar het om gaat: als je een goede reden hebt om het te doen en je levert er maintainable code mee op, moet je dat vooral doen. Tis hoe dan ook niet 'bizar', 'n00bish', 'minderwaardig' of 'het teken van aankutten' wat hierboven werd geinsinueerd.

Ik moest bij het lezen van dit topic direct denken aan Borland's VCL, waar je waardes in sets kon toevoegen door de volgende syntax:

C++:

1	myForm.sysIcons << siMaximize << siMinimize;

Dit is heel leesbare code die intuitief begrepen wordt als zijnde dat je die 2 waardes toevoegt aan de groep system icons. Maar << is in C++ net zo hard de bit-shift operator, die gewoon 2 integers als operands neemt en een integer 'hoort' te retourneren.

Als het met de bit-shift operator op tig verschillende manieren mag (zie ook iostream in STL overigens), waarom zou het voor lesser- en greater than niet mogen? Pak dan een taal zonder operator overloading als je daar niet tegen kunt

woensdag 20 juni 2007 15:58

Acties:

Woy

Moderator Devschuur®

Glimi schreef op woensdag 20 juni 2007 @ 14:44:
Helaas moet je denk ik wel concluderen dat C# in de huidige versie (3.0 even geen zicht op) daar gewoon geen features voor aanbied.

C# 3.0 heeft daar dus nu wel ondersteuning voor ( LINQ ). Wat ik er van gezien heb ziet het er vrij krachtig uit, maar ik heb er nog niet genoeg mee gewerkt om een goed oordeel te kunnen vellen.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

woensdag 20 juni 2007 16:09

Acties:

woensdag 20 juni 2007 16:19

.oisyn schreef op woensdag 20 juni 2007 @ 15:47:
Ik snap niet wat onze bedrijven hier ook maar enigszins mee te maken hebben.

Jij begon over mijn "wereldje". Gezien mijn ervaring vond ik dat ronduit denigrerend. Ik werk in een omgeving waarin ik gewoon afgerekend wordt op de kwaliteit van m'n werk, en een klant dus gewoon code geleverd krijgt in plaats van een gecompileerd werkend product. Ik vind opmerkingen als "jouw wereldje" en "gelukkig is jouw mening geen wet" gewoon vervelend. Als je op zo'n toon begint, reageer ik wat fel ja.

Dus even voor de goede orde, als je dit in een groot team zo afspreekt dan kan het wel, maar als je het in je eentje doet omdat je een hobbyist bent en daarom geen team achter je hebt staan, dan ben je een slechte programmeur? Juist als hobbyist kun je wat meer experimenteren en daarmee je eigen ervaring verrijken. Ik ben het er dan ook niet mee eens dat iemand dan meteen een slechte programmeur is.

Ten eerste: ik denk dat er geen enkel team is dat een dergelijke afspraak zou maken. Als iedereen in het team zo fucked up is dat ze dat normaal vinden, dan moeten ze maar lekker hun gang gaan ja

Ten tweede: iedereen maakt fouten, vooral in het begin. Juist daarom lijkt het me nuttig iemand te vertellen dat wat hij probeert te doen gewoon enorm ranzig is. Verder kan ik niet ruiken of iemand een functie heeft waarin hij programmeert of gewoon aan het hobbyen is. Kwa insteek ga ik er dus maar ergens middenin zitten.

Ik denk dat je je vergeet realiseren dat de topicstarter gewoon z'n probleem generiek probeert te beschrijven, en niet direct geïnteresseerd is in wat nou wel done en wat niet done is. Z'n probleembeschrijving is wat dat betreft vrij duidelijk, en met een antwoord op z'n vraag kan hij op weg om z'n implementatie wél leesbaar en intuitief te maken.

Hij probeert operator overloading te misbruiken voor iets waarvoor het niet bedoeld is, en waardoor iedere C# programmeur in ieder geval 3 keer heel hard moet gaan kijken voordat 'ie zou begrijpen wat de code nu precies doet. Waarschijnlijk zou iemand verkeerde aannames doen en d'r overheen lezen, gewoon omdat het niet logisch is. Dit is niet te vergelijken met eerder genoemde "syntactical sugar" omdat daar juist duidelijk is dat het een 'laagje erbovenop is'. Dat is volgens mij hier absoluut niet het geval.

curry684 schreef op woensdag 20 juni 2007 @ 15:57:
Tis hoe dan ook niet 'bizar', 'n00bish', 'minderwaardig' of 'het teken van aankutten' wat hierboven werd geinsinueerd.

Tja, ik vind het bizar. Kwestie van meningen. Ik heb overal een (sterke) mening over die ik graag uitdraag. Sue me

Ik moest bij het lezen van dit topic direct denken aan Borland's VCL, waar je waardes in sets kon toevoegen door de volgende syntax:
C++:
1
myForm.sysIcons << siMaximize << siMinimize;
Dit is heel leesbare code die intuitief begrepen wordt als zijnde dat je die 2 waardes toevoegt aan de groep system icons. Maar << is in C++ net zo hard de bit-shift operator, die gewoon 2 integers als operands neemt en een integer 'hoort' te retourneren.

Ik ben eerst met Java begonnen, en daarna met C++. Toen ik voor 't eerst cout<<"Hello world!"<<endl; zag had ik ook zo iets van "what the???". Ik vind dat ook gewoon enorm lelijk. Maargoed, ik vind C++, tenzij speed alles is, sowieso obsolete.

[ Voor 17% gewijzigd door Hydra op 20-06-2007 16:13 ]

https://niels.nu

Acties:

Glimi

Designer Drugs

rwb schreef op woensdag 20 juni 2007 @ 15:58:
C# 3.0 heeft daar dus nu wel ondersteuning voor ( LINQ ). Wat ik er van gezien heb ziet het er vrij krachtig uit, maar ik heb er nog niet genoeg mee gewerkt om een goed oordeel te kunnen vellen.

Ik heb even gelezen maar hoewel LINQ een SQL/Collectie DSEL toevoegd met het toevoegen van lambda syntax bied C# mijn inziens nog geen echte manier om operators te overloaden of nieuwe te definieeren. De syntax van de DSEL zit ingebakken in de taal, er is geen manier om te extenden. Ik kan niet 'nieuwe' operatoren toevoegen (Haskell voorbeeld: $>) die nog geen vaste betekenis hebben. Dat beperkt de DSEL te veel vind ik.

Ik zie de foutmeldingen al voor me

woensdag 20 juni 2007 16:29

Acties:

left part of the evil twins

Hydra schreef op woensdag 20 juni 2007 @ 16:09:
[...]

Jij begon over mijn "wereldje". Gezien mijn ervaring vond ik dat ronduit denigrerend.

Dude, hoe lang werk je al, jaar of 2? Kom over 5 tot 10 jaar eens terug over "jouw ervaring". Je wekt in dit topic iig de indruk dat je 5 a 6 jaar informatica hebt gestudeerd en nu meent over alles de wijsheid in pacht te hebben. Dat onderbouwen met dat je 'consultant' bent bij een groot bedrijf maakt het er niet beter op: de ervaren mensen hier weten wel dat de term 'consultant' bij grote bedrijven meestal gereserveerd is voor nutteloos volk dat voor veel te hoge prijzen bij klanten wordt neergezet om wat ervaring op te doen totdat ze een echte functieomschrijving krijgen.

Ten eerste: ik denk dat er geen enkel team is dat een dergelijke afspraak zou maken. Als iedereen in het team zo fucked up is dat ze dat normaal vinden, dan moeten ze maar lekker hun gang gaan ja

Refereer even terug aan mijn opmerkingen een stuk hierboven over bekrompenheid en gebrek aan ervaring. Door alles wat niet in jouw extreem kleine wereldje past als 'zo fucked up' te kwalificeren lok je bepaalde reacties ook wel enorm uit natuurlijk.

Ten tweede: iedereen maakt fouten, vooral in het begin. Juist daarom lijkt het me nuttig iemand te vertellen dat wat hij probeert te doen gewoon enorm ranzig is.

.....als je dat nou bewaart voor echt ranzige code in plaats van dingen die jij blijkbaar niet kent?

[...]

Tja, ik vind het bizar. Kwestie van meningen. Ik heb overal een (sterke) mening over die ik graag uitdraag. Sue me

Neuj ik zal je niet aanklagen. Wel vraagtekens plaatsen bij hoeverre je in deze community op je plaats bent als je geen ruimte biedt aan andere meningen als de jouwe.

Maargoed, ik vind C++, tenzij speed alles is, sowieso obsolete.

Daar heeft het dan ook een enorme markt mee.

woensdag 20 juni 2007 16:36

Acties:

woensdag 20 juni 2007 16:48

Moderator Devschuur®

Demotivational Speaker

Hydra schreef op woensdag 20 juni 2007 @ 16:09:

Jij begon over mijn "wereldje". Gezien mijn ervaring vond ik dat ronduit denigrerend.

Mijn punt is dat je doet voorkomen alsof elke serieuze professional net zo denkt als jij en (naar jou eigen zeggen) jouw klanten. Dat is gewoon niet zo en dat heb ik al laten zien. Dat jij daar een andere mening over hebt is natuurlijk jouw goed recht, maar je moet niet doen voorkomen alsof iedereen die er anders over denkt meteen onprofessioneel of "fucked up" is, want dat is gewoon niet zo. Ik was niet degene over jouw wereldje begon, je hebt zelf de deur open gezet door te beweren dat, and I quote:

D'r is no way dat dat van een collega geaccepteerd zou worden

Jouw collega's accepteren het misschien niet, maar er zijn wel degelijk professionele en competente collega's die het wél accepteren (wat uiteraard niet meteen betekent dat jij of je collega's niet competent zijn). Dát is wat ik probeerde te zeggen, niets denigrerends dus.

Ik werk in een omgeving waarin ik gewoon afgerekend wordt op de kwaliteit van m'n werk

En je denkt dat dat bij mij niet zo is?

en een klant dus gewoon code geleverd krijgt in plaats van een gecompileerd werkend product.

.edit: ik las verkeerd (gecompliceerd ipv gecompileerd)

[ Voor 10% gewijzigd door .oisyn op 20-06-2007 16:58 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

DrDelete

Het valt me wel op dat oisyn en hydra nogal expressief/agressief taalgebruik hebben en elk woord van voor naar achteren doodanalyseren, kun je op basis van je voorgaande posts niet leren om inhoudelijk bezig te zijn en niet constant elkaar te gaan flamen tot het bot ?
Dit soort reacties zijn niet nodig, daar hebben we moderators voor

[ Voor 22% gewijzigd door een moderator op 20-06-2007 16:50 ]

woensdag 20 juni 2007 17:29

Acties:

woensdag 20 juni 2007 17:32

curry684 schreef op woensdag 20 juni 2007 @ 15:57:
[...]

Ik moest bij het lezen van dit topic direct denken aan Borland's VCL, waar je waardes in sets kon toevoegen door de volgende syntax:
C++:
1
myForm.sysIcons << siMaximize << siMinimize;
Dit is heel leesbare code die intuitief begrepen wordt als zijnde dat je die 2 waardes toevoegt aan de groep system icons. Maar << is in C++ net zo hard de bit-shift operator, die gewoon 2 integers als operands neemt en een integer 'hoort' te retourneren.

Opnieuw, hier wordt de << operator gebruikt waarvoor hij bedoeld is; het toevoegen van een waarde aan een collectie van waarden. Dit geldt evenzo voor bits; de bit shift voegt bits toe aan een collectie van bits...

Alex Vanden Abeele

Acties:

woensdag 20 juni 2007 17:33

Admin Devschuur®

^ Romeinse Ⅲ ja!

al3x schreef op woensdag 20 juni 2007 @ 17:29:
de bit shift voegt bits toe aan een collectie van bits...

Wel? Volgens mij voegt een bitshift niets toe maar schuift 'ie bits

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

woensdag 20 juni 2007 17:38

Moderator Devschuur®

Demotivational Speaker

Nee, de shift voegt geen bits toe. De shift schuift bits op (en daarmee verlies je potentieel bits). Het zou een logische analogie zijn als de shift op containers werd gebruikt om de elementen in de container op te schuiven, waarbij elementen aan de ene kant eruit wordt gegooid en lege aan de andere kant worden geinsert, maar dat is niet het geval.

.edit: daar heb je die RobIII ook weer

[ Voor 6% gewijzigd door .oisyn op 20-06-2007 17:43 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 20 juni 2007 17:42

.oisyn schreef op woensdag 20 juni 2007 @ 17:33:
Nee, de shift voegt geen bits toe. De shift schuift bits op (en daarmee verlies je potentieel bits). Het zou een logische annalogie zijn als de shift op containers werd gebruikt om de elementen in de container op te schuiven, waarbij elementen aan de ene kant eruit wordt gegooid en lege aan de andere kant worden geinsert, maar dat is niet het geval.

.edit: daar heb je die RobIII ook weer

Ok, hij schuift bits, dus, worden vooraan toch nieuwe bits toegevoegd, met de waarde 0? Dus, maw worden elementen toegevoegd? Je kan een byte toch zien als een container van bits? Dat er aan de andere kant elementen uitvallen is slechts de implementatie van je container.

Alex Vanden Abeele

Acties:

woensdag 20 juni 2007 17:50

Moderator Devschuur®

Demotivational Speaker

Het punt is dat het rechter argument voor de shift opgeeft hoeveel bits je shift, en niet wat voor bits je insert. Daarnaast past de shift op een container die container aan. Een shift op een int past de int niet aan - hij geeft een nieuwe terug. Bovendien worden er geen elementen verwijderd, wat bij een bitshift wel zo is.

Ik blijf erbij dat ik je analogie niet correct vind

[ Voor 7% gewijzigd door .oisyn op 20-06-2007 17:43 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 20 juni 2007 18:01

Het punt is dat het rechter argument voor de shift opgeeft hoeveel bits je shift, en niet wat voor bits je insert.

Ok, daar volg ik in.

Daarnaast past de shift op een container die container aan.

Ook in het andere voorbeeld met de icons wordt de container aangepast; er zitten extra elementen in.

Een shift op een int past de int niet aan - hij geeft een nieuwe terug. Bovendien worden er geen elementen verwijderd, wat bij een bitshift wel zo is.

Je kan ints beschouwen als een fifo queue van bits; dus als die lijst van icons ook een fifo queue zou zijn heb je hetzelfde gedrag. kwestie van implementatie.

Ik blijf erbij dat ik je analogie niet correct vind

Ok, niet alla lettre, maar kan het niet als vergelijkbaar worden beschouwd?

Alex Vanden Abeele

Acties:

woensdag 20 juni 2007 18:09

curry684 schreef op woensdag 20 juni 2007 @ 16:29:
Dude, hoe lang werk je al, jaar of 2? Kom over 5 tot 10 jaar eens terug over "jouw ervaring". Je wekt in dit topic iig de indruk dat je 5 a 6 jaar informatica hebt gestudeerd en nu meent over alles de wijsheid in pacht te hebben.

Ik ben tijdens m'n studie begonnen bij een webdesignbedrijf als PHP programmeur, da's nu zo'n 8 jaar geleden. Ik werk bijna 6 jaar bij m'n huidige werkgever. Mijn meningen zijn vooral gebaseerd op ervaringen en niet op wat ik tijdens mijn studie geleerd heb. Dit ter info. Ik ben geen 'purist' omdat dat zo moet binnen een opleiding, maar omdat ik te veel klojo's heb meegemaakt die enorm ranzig werk afleverden.

Refereer even terug aan mijn opmerkingen een stuk hierboven over bekrompenheid en gebrek aan ervaring. Door alles wat niet in jouw extreem kleine wereldje past als 'zo fucked up' te kwalificeren lok je bepaalde reacties ook wel enorm uit natuurlijk.

Ach komop man. Een iets dikkere huid mag ook wel. Ik zeg dat ik iets fucked up vindt, boeiend.

.....als je dat nou bewaart voor echt ranzige code in plaats van dingen die jij blijkbaar niet kent?

Is goed, ik ga even topics uit 2004 uppen!

Neuj ik zal je niet aanklagen. Wel vraagtekens plaatsen bij hoeverre je in deze community op je plaats bent als je geen ruimte biedt aan andere meningen als de jouwe.

Het is een mening. Ik heb de mijne, jij de jouwe. Misschien moet je er eens mee leren omgaan dat als iemand zijn mening verdedigd dat niet meteen een persoonlijke aanval is.

Daar heeft het dan ook een enorme markt mee.

Gast, ons product is in C++ geschreven, ik weet dat er nog steeds een enorme markt voor is. Weet je, er is ook nog steeds een enorme markt voor COBOL.

.oisyn schreef op woensdag 20 juni 2007 @ 16:36:
Mijn punt is dat je doet voorkomen alsof elke serieuze professional net zo denkt als jij en (naar jou eigen zeggen) jouw klanten. Dat is gewoon niet zo en dat heb ik al laten zien. Dat jij daar een andere mening over hebt is natuurlijk jouw goed recht, maar je moet niet doen voorkomen alsof iedereen die er anders over denkt meteen onprofessioneel of "fucked up" is, want dat is gewoon niet zo. Ik was niet degene over jouw wereldje begon, je hebt zelf de deur open gezet door te beweren dat, and I quote:

Ach komop zeg! Die oplossing die de TS aandroeg is smerig, ik ben niet de enige die dat vind! Ik heb geen zin om hier verder een welles-nietes spelletje over te spelen, want ik geloof nooit dat iemand als C# (en ik heb het hier dus over de code van de TS!) programmeur met een dergelijke contructie weg zou komen.

Jouw collega's accepteren het misschien niet, maar er zijn wel degelijk professionele en competente collega's die het wél accepteren (wat uiteraard niet meteen betekent dat jij of je collega's niet competent zijn). Dát is wat ik probeerde te zeggen, niets denigrerends dus.

De oplossing van de TS?

En je denkt dat dat bij mij niet zo is?

[...]

.edit: ik las verkeerd (gecompliceerd ipv gecompileerd)

Je haalt dat stukje totaal uit z'n verband. Ik zou het op prijs stellen dat je niet een verhaal uit z'n verband haalt door een zin doormidden te quoten. Het punt is dat ik niet alleen door m'n collegae afgerekend wordt maar rechtstreeks door klanten die m'n code reviewen. Dat bedoel ik dus met dat het anders is dan een gecompileerd product opleveren; de code krijgen ze vaak niet te zien (hiermee vel ik dus geen waardeoordeel, ik vertel alleen waarom ik zo op code-kwaliteit hamer).

al3x schreef op woensdag 20 juni 2007 @ 17:29:
Opnieuw, hier wordt de << operator gebruikt waarvoor hij bedoeld is; het toevoegen van een waarde aan een collectie van waarden. Dit geldt evenzo voor bits; de bit shift voegt bits toe aan een collectie van bits...

In C++ libs wordt << in plaats van een shift ook wel eens de 'insertion operator' genoemd. Aangezien iedereen begint met cout<<"Hello world\n"; oid vind ik dat niet zo vreemd inderdaad. Ik vind het overigens nog steeds lelijk

[ Voor 7% gewijzigd door Hydra op 20-06-2007 18:04 ]

https://niels.nu

Acties:

woensdag 20 juni 2007 18:19

Hydra schreef op woensdag 20 juni 2007 @ 18:01:
Ik vind het overigens nog steeds lelijk

Er zijn wel nog zaken aan c++ die lelijk te noemen zijn

Alex Vanden Abeele

Acties:

woensdag 20 juni 2007 18:58

Moderator Devschuur®

Demotivational Speaker

Hydra schreef op woensdag 20 juni 2007 @ 18:01:
Ach komop zeg! Die oplossing die de TS aandroeg is smerig

Hebben we het nou over de oplossing van de TS, of het overloaden van de < operator die niet een comparison doet en een bool teruggeeft maar intern iets doet waar op een later moment iets semantisch vergelijkbaars uitkomt? Ik dacht namelijk over dat laatste.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 20 juni 2007 19:48

Moderator Devschuur®

Demotivational Speaker

al3x schreef op woensdag 20 juni 2007 @ 18:09:

Er zijn wel nog zaken aan c++ die lelijk te noemen zijn

Voornamelijk imho de allocator::rebind<> hack wegens het gemis van template typedefs, std::vector<bool>, de nogal intrusive ADL regels, de slechte friend specificatie in de standaard (waardoor iedere implementor er z'n eigen draai aan geeft) en het gemis van template argument constraints voor duidelijkere errormeldingen.

Gelukkig wordt aan alle punten wat gedaan muv ADL en std::vector<bool> wegens backwards compatibility. Met name Concepts is een heerlijke feature die mooi generiek programmeren toegankelijker maakt.

[ Voor 11% gewijzigd door .oisyn op 20-06-2007 19:00 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

woensdag 20 juni 2007 21:09

f0pc0dert

Hydra:
Ten eerste: ik denk dat er geen enkel team is dat een dergelijke afspraak zou maken. Als iedereen in het team zo fucked up is dat ze dat normaal vinden, dan moeten ze maar lekker hun gang gaan ja

Wat een onzin zeg. Als ieder lid in een team zo fucked up is dat 'ie denkt dat dergelijke features voor niks in een taal zijn gestopt, dan moeten ze allemaal een pak rammel krijgen en eens na gaan denken over de vraag waarom je niet creatief wilt zijn als je een programmeur bent. Dat je het weloverwogen toe moet passen, goed moet overleggen en last but not least goed moet documenteren, of misschien wel gewoon alleen als braintrainer moet doen, is iets anders, maar een "wat de boer niet kent dat vreet'ie niet"-houding is echt killing voor elke vorm van innovativiteit, en als dat is wat je wilt bereiken, vraag ik me sterk af wie er nou fucked-up is.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

Zr40

Moderator General Chat

heeft native IPv6

drm schreef op woensdag 20 juni 2007 @ 19:48:
[...]
Wat een onzin zeg. Als ieder lid in een team zo fucked up is dat 'ie denkt dat dergelijke features voor niks in een taal zijn gestopt, dan moeten ze allemaal een pak rammel krijgen en eens na gaan denken over de vraag waarom je niet creatief wilt zijn als je een programmeur bent.

Om even niet op specifieke talen in te gaan: niet elke taal is perfect. Er kunnen wel degelijk misfeatures in een taal zitten. Zinnige programmeurs vermijden die features dan ook, in plaats van het 'creatief' te gebruiken.

donderdag 21 juni 2007 08:43

Acties:

donderdag 21 juni 2007 10:50

f0pc0dert

Zr40:
Om even niet op specifieke talen in te gaan: niet elke taal is perfect. Er kunnen wel degelijk misfeatures in een taal zitten.

Mijn ervaring is eerder dat het niet perfect zijn van een taal juist komt door het ontbreken van bepaalde features, maar goed dat even terzijde

Zinnige programmeurs vermijden die features dan ook, in plaats van het 'creatief' te gebruiken.

Ik vraag me dus af of je dat waardeoordeel "zinnig" (of "fucked-up" for that matter) er wel aan kunt hangen. Het is altijd de vraag wanneer je bepaalde dingen wel en niet moet gebruiken en bij voorbaat features van een taal uitsluiten, ongeacht de situatie, is imho beperkender dan nodig is.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

donderdag 21 juni 2007 11:12

al3x schreef op woensdag 20 juni 2007 @ 18:09:
Er zijn wel nog zaken aan c++ die lelijk te noemen zijn

Ik probeer zoveel mogelijk C++ projecten te vermijden

Gelukkig is het meeste werk dat ik do C#/Java gebaseerd.

.oisyn schreef op woensdag 20 juni 2007 @ 18:19:
Hebben we het nou over de oplossing van de TS, of het overloaden van de < operator die niet een comparison doet en een bool teruggeeft maar intern iets doet waar op een later moment iets semantisch vergelijkbaars uitkomt? Ik dacht namelijk over dat laatste.

Hmm. De volgende keer dat je offtopic gaat moet je dat dan misschien even melden, want ik heb het nog steeds redelijk specifiek over de oplossing van de TS. Ik zeg ook nergens dat operator overloading per definitie lelijk is, ik zeg dat je het moet gebruiken voor dingen die logisch zijn.

drm schreef op woensdag 20 juni 2007 @ 19:48:
Wat een onzin zeg. Als ieder lid in een team zo fucked up is dat 'ie denkt dat dergelijke features voor niks in een taal zijn gestopt, dan moeten ze allemaal een pak rammel krijgen en eens na gaan denken over de vraag waarom je niet creatief wilt zijn als je een programmeur bent. Dat je het weloverwogen toe moet passen, goed moet overleggen en last but not least goed moet documenteren, of misschien wel gewoon alleen als braintrainer moet doen, is iets anders, maar een "wat de boer niet kent dat vreet'ie niet"-houding is echt killing voor elke vorm van innovativiteit, en als dat is wat je wilt bereiken, vraag ik me sterk af wie er nou fucked-up is.

Heb ik ooit gezegd dat operator overloading per definitie slecht is?

https://niels.nu

Acties:

donderdag 21 juni 2007 11:43

Moderator Devschuur®

Demotivational Speaker

Als meerdere mensen je verkeerd interpreteren, kan het dan wellicht niet zo zijn dat je zelf een beetje onduidelijk was?

. In het begin leek je namelijk erg te argeren tegen "vaag" gebruik van overloaded operators in het algemeen (zoals bijv. om een SQL statement mee te bouwen). Nu nuanceer je dat wat en heb je het meer over het gebruik zoals de TS dat doet (dus als losse statements).

Dus om de boel wat te verduidelijken, ik vind de aanpak van de TS ook niet optimaal, maar mij persoonlijk lijkt het me erg handig als je zou kunnen zeggen

C#:

SQLQueryBuilder sql = new SQLQueryBuilder();
sql.select(a.propertyA, b.propertyB);
sql.from(a, b); // of wellicht is deze af te leiden uit de select() ?
sql.where(a.propertyA > 4 && b.propertyB == "woei");

[ Voor 85% gewijzigd door .oisyn op 21-06-2007 11:46 . Reden: ambiguity van 'b' weggehaald ;) ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

donderdag 21 juni 2007 12:08

.oisyn schreef op donderdag 21 juni 2007 @ 11:12:
Als meerdere mensen je verkeerd interpreteren, kan het dan wellicht niet zo zijn dat je zelf een beetje onduidelijk was? . In het begin leek je namelijk erg te argeren tegen "vaag" gebruik van overloaded operators in het algemeen (zoals bijv. om een SQL statement mee te bouwen). Nu nuanceer je dat wat en heb je het meer over het gebruik zoals de TS dat doet (dus als losse statements).

Dus om de boel wat te verduidelijken, ik vind de aanpak van de TS ook niet optimaal, maar mij persoonlijk lijkt het me erg handig als je zou kunnen zeggen
C#:
1
2
3
4
SQLQueryBuilder b = new SQLQueryBuilder();
b.select(a.propertyA, b.propertyB);
b.from(a, b); // of wellicht is deze af te leiden uit de select() ?
b.where(a.propertyA > 4 && b.propertyB == "woei");

Precies, dat is ook wat wij doen in onze O/R mapper query syntaxis. Het geeft compile-time checked code en niet van die string-based queries. Natuurlijk is het eigenlijk een hack, maar wat moet je anders, wanneer de taal zelf (C# of VB.NET) geen mogelijkheid geeft om zelf operators te definieren...

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

Verwijderd

Topicstarter

EfBe schreef op donderdag 21 juni 2007 @ 11:43:
[...]

Precies, dat is ook wat wij doen in onze O/R mapper query syntaxis. Het geeft compile-time checked code en niet van die string-based queries. Natuurlijk is het eigenlijk een hack, maar wat moet je anders, wanneer de taal zelf (C# of VB.NET) geen mogelijkheid geeft om zelf operators te definieren...

Mag ik vragen met welke code je dit hebt bewerkstelligd?

donderdag 21 juni 2007 12:45

Acties:

donderdag 21 juni 2007 13:41

Verwijderd schreef op donderdag 21 juni 2007 @ 12:08:
[...]
Mag ik vragen met welke code je dit hebt bewerkstelligd?

Dat mag

Je moet zoeken naar objects die je kunt gebruiken om je query te bouwen. In ons systeem zijn dat field objects, die een entity field representeren. Daarmee kun je lists bouwen maar ook queries. Op de field classes zijn allerlei operators overloaded, zoals ==, <= etc. Die overloads returnen dan een filter object. Dus je kunt dit schrijven:

C#:

1	IPredicate p = new FieldCompareValuePredicate(CustomerFields.CompanyName, ComparisonOperator.Equals, "Tweakers.NET BV");

maar je kunt datzelfde ook krijgen door:

C#:

1	IPredicate p = (CustomerFields.CompanyName == "Tweakers.NET BV");

CustomerFields.CompanyName geeft een entityfield object terug die company name in de customer entity representeert. De '==' operator is overloaded op entityfield en returned een FieldCompareValuePredicate object.

Expressies werken ook zo, Als je doet:

C#:

1	IExpression e = (OrderDetailFields.Quantity * OrderDetailFields.Price);

dan is e idem aan:

C#:

1	new Expression(OrderDetailFields.Quantity, ExOp.Mul, OrderDetailFields.Price);

en de '*' operator is overloaded op entityfield en die returnt een new Expression object met de left en right operands.

Dat doe je zo:

C#:

/// <summary>
/// Operator overload for the '*' operator to produce an Expression which represents field * field2
/// </summary>
/// <param name="leftOperand">Left operand.</param>
/// <param name="rightOperand">Right operand</param>
/// <returns>Expression object which represents field * field2</returns>
public static Expression operator*(EntityField leftOperand, EntityField rightOperand)
{
    return new Expression(leftOperand, ExOp.Mul, rightOperand);
}

de compiler zorgt er wel voor dat de juiste overload wordt aangeroepen, want er is ook een * overload voor bv:

C#:

/// <summary>
/// Operator overload for the '*' operator to produce an Expression which represents value * field
/// </summary>
/// <param name="value">Value.</param>
/// <param name="rightOperand">Right operand.</param>
/// <returns>
/// Expression object which represents value * field
/// </returns>
public static Expression operator*(object value, EntityField rightOperand)
{
    if(value is IEntityField)
    {
        return ((EntityField)value * rightOperand);
    }
    return new Expression(value, ExOp.Mul, rightOperand);
}

Het is alleen wel zaak niet te overdrijven. In dit kader werkt het goed, want de '*' operator en de '==' operator hebben geen of bar weinig nut op entity field objects in-memory. Wanneer dat wel het geval zou zijn, dan heb je een probleem want dan ga je code schrijven als:
IEntityField f1, f2;
// set f1, f2 to an instance by calling a method;
if(f1==f2)
{...
}

en dat gaat natuurlijk fout. Dus pas het toe wanneer je geen ambigue constructies kunt maken. In het kader van query building heb je geen ambigue situaties, maar in veel andere gevallen wel.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

Niemand_Anders

Dat was ik niet..

Hij wil niet dat de kleiner dan operator wordt aangepast, hij wil dat a.ProductID < 5 wordt vertaald naar ' where ProductID < 5'. Hij wil dus *geen* vergelijking uitvoeren (althans pas op de database)

Hieronder een basis opzet van wat je wilt. Helaas moet een operator vergelijking wel aan 'iets' worden toegekend. Het mag dus geen statement zijn. Je kunt dus helaas niet 'bool a =' weglaten. Ook mag de operator geen 'void' terug geven. Op een vergelijkbare manier kun je ook de andere operators implementeren. Wil je ook datums kunnen gebruiken, dan zul je dus ook een DatabaseDateTime moeten maken. Deze 'database types' kun je dan gebruiken in andere classes (zoals ProductQuery)

Onderstaande levert het volgende op:
DB Query: select * from products where ProductID < 5

Ik hoop dat dit je een eind op weg helpt.

code:

namespace Database
{
    class Test
    {
        public static void Main(string[] args)
        {
            ProductQueryq = new ProductQuery();
            bool a = q.ProductId < 5;   //de vergelijking zelf wordt genegeerd

            Console.WriteLine("DB Query: {0}<br />", q.MakeQuery());
        }

    }

    class ProductQuery
    {
        public DatabaseNumber ProductId;

        public ProductQuery()
        {
            this.ProductId = new DatabaseNumber(0);
        }

        public string MakeQuery()
        {
            return string.Format("select * from products where {0}", this.ProductId.ToString());
        }
    }

    class DatabaseNumber
    {
        private string whereParam;
        private long databaseValue;

        public DatabaseNumber(long value)
        {
            this.databaseValue = value;
        }

        public long Value 
        {
            get { return this.databaseValue; }
            set { this.databaseValue = value; }
        }

        public override string ToString()
        {
            return whereParam;
        }
        
        //here come the static overloaded operators. 
        public static bool operator < (DatabaseNumber a, long v)
        {
            a.whereParam = "ProductID < " + v.ToString();
            a.databaseValue = v;
            return false;   //required to return a value
        }

        public static bool operator > (DatabaseNumber a, long v)
        {
            a.whereParam = "ProductID > " + v.ToString();
            a.databaseValue = v;
            return false;   //required to return a value
        }
    }
}

If it isn't broken, fix it until it is..

donderdag 21 juni 2007 15:42

Acties:

Zr40

Moderator General Chat

heeft native IPv6

Niemand_Anders: jouw oplossing negeert de mogelijkheid om expressies te combineren via bijvoorbeeld &&.

donderdag 21 juni 2007 16:23

Acties:

Mastermind

Ik zie ook niet in waarom het gebruik van operators zoals de TS wil niet goed zou zijn. Wij gebruiken binnen ons bedrijf LLBLGen en het werkt zeer handig om querie-predicaten te definieren.

C#:

PredicateExpression predicateEx = null;
RelationCollection relationCol = new RelationCollection();
DateTime yesterday = today.AddDays(-1);
DateTime tomorrow = today.AddDays(2);
relationCol.Add(KvorderItemsTijdsbalkEntity.Relations.KvorderItemsEntityUsingKvorderItemsId);
IPredicate iPredicate = (
KvorderItemsTijdsbalkFields.BeginDatumTijd > yesterday &
KvorderItemsTijdsbalkFields.BeginDatumTijd < tomorrow  &
KvorderItemsTijdsbalkFields.EindeDatumTijd > yesterday &
KvorderItemsTijdsbalkFields.EindeDatumTijd < tomorrow
)  
// Moet aan een resource toegewezen zijn:
& !new FieldCompareNullPredicate(KvorderItemsTijdsbalkFields.ResourceId); 
predicateEx = new PredicateExpression(iPredicate);
tijdsbalkCol.GetMulti(predicateEx, relationCol); // Get resultset

Heerlijk dat LLBLGen $_/-\o_$

donderdag 21 juni 2007 17:23

Acties:

donderdag 21 juni 2007 17:50

Je kunt:
& !new FieldCompareNullPredicate(KvorderItemsTijdsbalkFields.ResourceId);
nog vervangen door:
& (KvorderItemsTijdsbalkFields != DBNull.Value);

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

Mastermind

* Mastermind geeft EfBe een pluim.

Hoe spreek je LLBLGen trouwens uit, en waar staat het voor?

[ Voor 12% gewijzigd door Mastermind op 21-06-2007 17:51 ]

donderdag 21 juni 2007 18:11

Acties:

donderdag 21 juni 2007 23:10

Admin Devschuur®

^ Romeinse Ⅲ ja!

Mastermind schreef op donderdag 21 juni 2007 @ 17:50:
* Mastermind geeft EfBe een pluim.

Hoe spreek je LLBLGen trouwens uit, en waar staat het voor?

offtopic:
Uitspraak
Dit is het enige dat ik zo snel kon vinden qua betekenis.

_{Ik/wij gebruiken het ook en het is echt}

[ Voor 23% gewijzigd door RobIII op 21-06-2007 18:17 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

vrijdag 22 juni 2007 08:52

Lower Level Business logic Layer Generator

Bedankt voor alle complimenten!

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

vrijdag 22 juni 2007 11:27

f0pc0dert

Lower Level Business logic Layer Generator

Pff, de afkortingen waren op, of niet?

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Acties:

HawVer

Ik ben heel deels eens met Hydra.. Als een programmeur op eigen houtje binnen een groot project zonder overleg standaard operators overload is ie imho gewoon fout bezig. Er zijn nogal wat randvoorwaarden voordat je standaard functionaliteit zomaar veranderd.

Die nieuwe functionaliteit moet goed ingesloten zijn. Stel voor dat iemand anders uit een project diezelfde operator op een 'juiste' (volgens de standaard) manier wil gebruiken maar de operator ineens een andere functionaliteit krijgt, dat lijkt me een onwerkbare situatie. Als je die functionaliteit goed dichttimmert en je zorgt ervoor dat je uitgebreid documenteert en dat de rest van de projectleden op de hoogte zijn lijkt me dat geen probleem.

Het voorbeeld dat oisyn op pagina 1 aandraagt vind ik een mooie en duidelijke oplossing. Het is duidelijk dat je een expressie als operator meegeeft. Het is in één opzicht duidelijk hoe je die functionaliteit dient te gebruiken. De code voorbeelden die de TS aandraagt vind ik daarentegen onduidelijk en ondoorzichtig. Je moet het verhaal drie keer overlezen voordat je een beeld krijgt van de functionaliteit. Het is belangrijk dat je daar een wel overwogen keuze in maakt.

Daarnaast is het wel erg interessant om mee te testen.

http://hawvie.deviantart.com/

vrijdag 22 juni 2007 13:06

Acties: