> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Pierre van Rooden > > Rob van Maris wrote: > > These are the design principles. They have been the guiding > principles > > from the outset, and applied consistently. If you don't > agree it's too > > late to change it now. We'll agree to disagree. > > That si afine way to argue stuff. It's too late to change things, > because now is when you decide to discuss it?
No. It's too late to change the design. I think the ad-hoc modification you suggested justifies spoiling the consistency of the whole. Besides, we *did* this outside of the mailinglist already, so I quote the motivation I sent you here (sorry, no translation): Hierbij mijn motivatie: 1 - separation of responsibilities: het query framework is ontworpen als een lightweight framework. Hiermee wordt bedoeld dat het niet meer functionaliteit moet bieden dan het minimum, noodzakelijk voor het uitvoeren van zijn primaire verantwoordelijkheid, n.l. het representeren van queries. De conversies waar je op doelt, behoren niet tot deze verantwoordelijkheden, en dient hier dus geimplementeerd te worden. Deze scheiding van verantwoordelijkheden is een erkende 'best practice' in OO kringen. 2 - eenvoud en helderheid: FieldValueConstraint heeft een property "value", de implementatieklasse BasicFieldValueConstraint heeft een methode om deze property te zetten (zie apidoc): setValue(). Dit suggereert dat de waarde van de property gelijk is aan de waarde die gebruikt is als argument voor setValue(). Met jouw wijzigingen is dit niet meer het geval. Een vergelijkbare situatie doet zich voor bij FieldValueInConstraint en FieldValueBetweenConstraint. Jouw wijziging doet dus afbreuk aan de eenvoud en helderheid van de code. 3 - robustness: het is volstrekt ongewenst om business rules als "hoe krijg ik het objectnummer van een Node of MMObjectNode", "hoe krijg ik het objectnummer dat hoort bij een alias" op talloze plekken in te bouwen. Dit soort logic hoort (inderdaad) zoveel mogelijk gecentraliseerd te worden, en uitgevoerd voordat resultaten aan een andere laag worden doorgegeven (query framework). Deze werkwijze bevordert de robuustheid van de code. Dit is ook de reden waarom de conversie van een string naar numerieke waarde al direct in de parser hoort plaats te vinden. Rob
