🚀 go-pugleaf

Dr.Ruud wrote:

> Toen ik John Bokma kietelde, kwam er dit uit:
>> Dr.Ruud:
> 
>>> Het blijft altijd verstandig om zo te coderen dat 'M' niet aan
>>> sex wordt toegekend als sex al 'M' is; je weet immers niet of
>>> dat extra acties tot gevolg heeft,
> 
>> Natuurlijk *weet* je dat wel.
> 
> Dat ligt eraan hoe je zo'n stuk code opvat.

Natuurlijk niet.

> "sex = 'M'"
> is een toekenning, wat meestal simpelweg betekent dat een
> geheugenplaats een andere waarde krijgt. Maar er zijn
> talloze omstandigheden waarin op 'schrijven' een dusdanige
> 'straf' staat, dat je het met alle macht probeert te
> vermijden.

Dan hoort dat ergens netjes gedocumenteerd te zijn. Het is een extreem
krom om te programmeren op een situatie die gewoon niet op *kan* treden. 

>>> zoals een refresh van een
>>> window, of een update in een wereldwijd gerepliceerde database.
>>
>> Ik vind het altijd een zeer kwalijke zaak als men programmeerd op
>> "het zou wel eens kunnen".
> 
> Als het niet meer moeite kost om er wel rekening mee te houden,
> dan doe ik dat toch graag.

Maar je verwart daar de lezer mee en/of het is een optimalisatie die
nergens op slaat. Testen of iets niet M is en dan pas op M zetten is
vaak duurder dan de variabele gewoon altijd zetten. 

Het is minder code enz.

> Het gaat dan om vrij algemene code
> die in meerdere omgevingen onaangepast bruikbaar is. En met die
> switch{} lukt dat heel aardig.

Vreselijk. Dus jij gaat er vanuit dat elke variabele aanpassen zomaar
een dure operatie kan zijn? 

>> Een ander voorbeeld:
>>
>> i = 1;
>> while (1) {
>>
>>     ... code die i *niet* aanpast;
>>     i++;
>>     if ( i > 10 ) break;
>> }
>>
>> i kan niet groter dan 10 worden, dus waarom in hemelsnaam daar op
>> testen? Ik zou dus i == 10 er van maken, want.. i > 10 zet mij aan
>> het denken, waar wordt i nog meer aangepast.
> 
> Dat wordt inderdaad vaak zo wordt gecodeerd.

Wat vreselijk is. i *kan niet* groter worden, dus onzin om te testen of
het groter is dan 10. Verwarring ten top. 

> Een for-loop is daar
> natuurlijk meer op zijn plaats, maar dat is niet wat je aan wilt
> geven. Eigenlijk zou je een 'assert(i<10)' voor de i++ moeten
> zetten, en dan daarna inderdaad 'if (i == 10)' gebruiken.

Waarom?

Je doet toch ook niet:

a = 5;
assert( a!= 5);
a++;
assert( a!= 6);

> Tout-le-monde codeert: for (i=0; i < 10; i++)

Maar i kan kleiner dan 10 zijn. In mijn voorbeeld kan i *nooit* groter
dan 10 worden. Ik hoorde ooit iemand noemen: maar stel dat i toevallig
door een bug wel groter wordt dan 10.... 

>> Dus iets a la:
>>   if ( var != 'M' ) var = 'M';
>> als gewoon
>>   var = 'M';
>> volstaat, zou ik zeer zeker aanraden. (Is wellicht zelfs sneller,
>> en bovenal minder ruis).
> 
> Als het volstaat, dan OK. Maar als er side-effects zijn, dan wordt
> het anders.

Uiteraard, maar dan en slechts dan ga je er anders mee om, IMNSHO.

> Dat er bijvoorbeeld een dirty-flag wordt gezet, of een
> oldvalue-property aangepast wordt, etc.

In Perl kan dat soort dingen prachting met tie. Je kan een variable
tie-en, en voor diverse zaken worden dan functies aangeroepen in een
module, b.v. schrijven naar de var, lezen van etc. Met arrays kan je
dingen als push, pop, etc etc allemaal afvangen. Klassieke voorbeelden
zijn b.v. een hash met tie koppelen aan een database, en vervolgens kan
je inderdaad met: 

$table{ $primary_key } = $value;

eventjes aan de andere kant van de wereld een database updaten :-D.

> In C zou je daar een define van kunnen maken, met in de ene
> omgeving dit:
>   #define SET( var, value ) (if ((var) != (value)) {(var) = (value);})
> en in de andere dit:
>   #define SET( var, value ) ((var) = (value))
> al zijn die niet echt evenwaardig, denk aan "if (SET(a,10))".
> 
> En in C++ heb je ook nog operator-overloading.

Yup, en ik ken maar een paar situaties waarin dit echt handig is. Perl
kan het ook, maar ik heb nog nooit er gebruik van gemaakt. (Alleen een
keertje om er naar te kijken). 

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html