[DISCUSSIE] This or not to this (relatieve paden/scopes)

[TrueChaoZ]

Jaja that's the question. This or not to this.

Naar aanleiding van de interessante relatieve vs. absolute paden discussie in het 'Gebruik van _root' (http://www.flashfocus.nl/forum/showthread.php?t=2969) topic heb ik hier een vervolg op bedacht. De meeste mensen hier zien relatieve paden als een must voor in ieder geval websites en webapplicaties (in feite met classes ben je ook relatief bezig IMO), voor de performance van games lijkt het iets minder een must. Maar wat vinden de mensen van het continu gebruik van 'this', laat je het weg of zet je het overal expliciet neer. Ik zal mijn mening nog even achterwege laten zodat jullie zelf kunnen nadenken en hierop kunnen reageren.

Stelling: This or not to this.

[Tha Narie]

Ik doe het niet, maar dat is denk ik omdat ik soms nogal lui ben :P

[Roenes]

Ik gebruik this alleen waar het nodig is. Stel je hebt een class:

class Test
{
private var myVar;

function Test(myVar)
{
this.myVar = myVar; //Hier dus wel
}

public function getVar()
{
return myVar; //Hier dus niet
}
}
Even een vlugge weergave die misschien niet helemaal correct is (en iig geen typechecking heeft). Zoals je ziet doe ik this in de constructor wel gebruiken vanwege de dubbele namen maar in de get methode doe ik dat niet omdat het logisch is welke var het is. Dan vind ik het gebruik van this weer wat overbodig.

Ook vind ik het rommelig staan als er overal this staat terwijl het eigenlijk niet hoeft. Mensen zeggen dan vaak dat het wel zo netjes is en consistent om overal this te gebruiken, maar als het niet nodig is en niet bijdraagt aan de leesbaarheid van de code laat ik het meestal weg. :)

[Tha Narie]

Het zou wel moeten, omdat je op die manier het verschil kunt zien tussen een object-variable en een lokale functie-variable.

[Roenes]

Klopt, maar eigenlijk is het logisch dat je met de get methode de object var wil opvragen. Dit wordt over het algemeen ook zo opgevat. Maar je kan duidelijk het verschil aangeven met this. Maar ik doe het dus niet omdat ik het overbodig vind ;)

[TrueChaoZ]

Klopt, maar eigenlijk is het logisch dat je met de get methode de object var wil opvragen. Dit wordt over het algemeen ook zo opgevat.Een erg gewaagde opmerking, hoe weet jij dat dit overal en in het algemeen zo opgevat wordt ;)

Ik gebruik this alleen waar het nodig is. Stel je hebt een class:

class Test
{
private var myVar;

function Test(myVar)
{
this.myVar = myVar; //Hier dus wel
}

public function getVar()
{
return myVar; //Hier dus niet
}
}
Even een vlugge weergave die misschien niet helemaal correct is (en iig geen typechecking heeft). Zoals je ziet doe ik this in de constructor wel gebruiken vanwege de dubbele namen maar in de get methode doe ik dat niet omdat het logisch is welke var het is. Dan vind ik het gebruik van this weer wat overbodig.

Ook vind ik het rommelig staan als er overal this staat terwijl het eigenlijk niet hoeft. Mensen zeggen dan vaak dat het wel zo netjes is en consistent om overal this te gebruiken, maar als het niet nodig is en niet bijdraagt aan de leesbaarheid van de code laat ik het meestal weg. :)
Ik zou sowieso proberen te voorkomen om dubbele variabelen te gebruiken dan kan je helemaal zonder this werken ;) Maar ik zelf doe this zo veel mogelijk gebruiken, dat is dus altijd en overal. Het verbeterd juist code duidelijkheid en zodoende kan er geen misverstand bestaan over in welke scope je aan het werken bent met de variabele. Ook werk ik sinds korte tijd veel met de 'with () {}' structuur. Bijvoorbeeld:
target.createTextField("statusTxt", target.getNextHighestDepth(), 0, 10, 0, 0);
this.statusTxt = target.statusTxt;
with (this) {
statusTxt.autoSize = true;
statusTxt.type = "dynamic";
statusTxt.selectable = false;
statusTxt.text = "loading";
}

[Roenes]

en with vind ik weer veel onoverzichtelijker. Zeker als je een groter stuk code hebt. Nu staat er alleen this in de with, maar wat als er een langer path staat? Je kijkt dan naar regels code in de with, maar in eerste instantie zie je niet dat er nog een path voor hangt. Aan het inspringen kun je dat niet opmaken omdat je heel vaak inspringt om verschillende redenen.

Doordat je het path niet ziet, zou ik persoonlijk sneller aan pathfouten denken. Als je dan toch het path wil inkorten, sla het dan op in een var waardoor het wel duidelijk is dat er een path voor je statement zit:
var mc = this._parent._parent.mcA.mcX;
mc._x = 100;
mc._y = 10;
mc._width = 150;
mc.onEnterFrame = function()
{
trace("Doe maar wa");
}
Je ziet nu bij ieder statement dat er een path voor staat, wat het path precies is weet je niet direct maar er wordt iig wel aangegeven dat er een path zit. Persoonlijk vind ik dit dus duidelijker als werken met with :)

[Pimm]

Ik vind dat this altijd kan, het geeft namelijk overzicht en vaag moet het ook (denk aan in een function). Ik gebruik het dus wel om twee redenen: Het is overzichtelijk. Als je het niet doet als het niet hoeft ga je het vanzelf ook niet doen als het wel moet.
I .. ..
::::.::::
:::::::::
:::::::
:::::
:::
: This

[Dauntless]

Some people will obsessively put "this" in front of every method call and frield reference, arguing that it makes it "clearer and more explicit". Don't do it. There's a reason that we use high-level languages: They do things for us. If you put 'this' in when it's not necessary, you will confuse and annoy evryone who reads your code, since all the rest of the code they've read won't use this evrywhere. Following a consistent and straightforward coding style saves time and money
En ik ga hier dan ook mee akkoord... Ik gebruik vaak 'this', maar zeker NOOIT altijd!

(Ohja, dit komt uit "Thinking in Java" van Bruce Eckel (3th edition), 0-13-100287-2, pagina 180 onderaan, voetnoot 2 :p)

[TrueChaoZ]

@Roenes
Je hebt daar idd wel wat punten, ik gebruik het persoonlijk ook wel vaak beide, maar dat is een ander onderwerp.

En ik ga hier dan ook mee akkoord... Ik gebruik vaak 'this', maar zeker NOOIT altijd!

(Ohja, dit komt uit "Thinking in Java" van Bruce Eckel (3th edition), 0-13-100287-2, pagina 180 onderaan, voetnoot 2 :p)
Ok en sinds wanneer is elke Guru, in wat voor taal dan ook, degene die bepaald wat wij doen ;)
En dit is natuurlijk een dubieus stukje: "since all the rest of the code they've read won't use this evrywhere". Hoe weet hij nou zeker dat er voor de rest nooit this gebruikt wordt, ja als hij het zegt dat iedereen het moet doen, dan doet iedereen het ook. En AS is nog steeds geen Java in mijn ogen.

Ik ben het dan ook zeer met Pimm eens, goede punten die hij daar heeft. Ik vind het ook overzichtelijker werken met this, maar blijkbaar vind niet iedereen dit, en ik denk ook dat als je het niet gebruikt er luiheid kan ontstaan. Daarnaast is het ook zo dat als jij 'this' soms wel en dan weer niet gebruikt, dat jijzelf gaat bepalen wanneer het nou eigenlijk wel moet en niet moet. Dus je zet gewoon geen 'this' overal bij totdat de compiler met een error komt, of totdat je er achter komt dat je code niet klopt? Dat is mijn ogen gewoon tijdverspilling, gebruik je overal gewoon 'this' dan is het altijd duidelijk en uniform.

[Dauntless]

Nee, AS is geen Java, maar ze steunen toch beide op het ECMA 4 voorstel, wat toch zorgt voor aardig wat gelijkenissen ...

En als er nooit iemand een ander persoon z'n ID volgt, komen er nooit best practices hé ;).

[De Kale]

je zit al in een class/object, dus this is overbodig, ik ben het helemaal eens met dauntless en de quote die hij geeft.

wat betreft het verschil tussen een propertie en een input var/lokale var moet je er wel goed op letten, maar ideaal gesproken zou je die al door de naamgeving uit elkaar houden (bijvoorbeeld prefixen met p(parameter) voor input vars oid.)

[oh,when?]

je zit al in een class/object, dus this is overbodig, ik ben het helemaal eens met dauntless en de quote die hij geeft.

wat betreft het verschil tussen een propertie en een input var/lokale var moet je er wel goed op letten, maar ideaal gesproken zou je die al door de naamgeving uit elkaar houden (bijvoorbeeld prefixen met p(parameter) voor input vars oid.)
Sluit me bij Rolf aan, plus wij gebruiken voor method paramaters altijd een vrij simpele naamgeving:

public function myMethod( inFoo: String, inBar: Number ) : Void {
foo = inFoo;
bar = inBar;
}

tres simple en leesbaar :)

[Roenes]

Owen, even totaal offtopic maar nu wil ik het toch weten. :) Jouw naam doet een belletje bij me rinkelen maar ik weet niet waarvan en uit je profiel kan ik het ook niet helemaal halen.

Kan het kloppen dat ik je naam ken van een of andere groot bedrijf of grote naam uit de flashwereld? Want jouw naam komt me zo bekend voor :p

[Tha Narie]

Owen van Dijk, werkte voorheen bij Clockwork, is betrokken bij bijna alles wat MacroMedia maakt :P

blog: http://ohwhen.typepad.com/mx_traveller/

[Roenes]

Clockwork, dank je dat was het :)

Dan weet ik weer uit welke hoek die naam komt :p

[oh,when?]

Owen, even totaal offtopic maar nu wil ik het toch weten. :) Jouw naam doet een belletje bij me rinkelen maar ik weet niet waarvan en uit je profiel kan ik het ook niet helemaal halen.

Kan het kloppen dat ik je naam ken van een of andere groot bedrijf of grote naam uit de flashwereld? Want jouw naam komt me zo bekend voor :p

De meeste mensen kennen me vanwege de MXUG die ik toenertijd gestart ben, of vanwege de presentaties die ik gegeven heb ( paar keer Flashtival, MXDU, aankomend Spark Europe, Macromedia presentaties, laatst nog in Utrecht ), of idd vanwege mijn betrokkenheid bij het Macromedia Flash Platform. Daarnaast heb ik een kleine 2 jaar bij Clockwork gewerkt, en daarvoor zo'n anderhalf jaar bij de TROS. En sinds dit jaar mijn eigen Flash studio :)

[TrueChaoZ]

Ik wil even alle mensen bedanken voor hun mening tijdens deze discussie, feel free to add more to it, maar ik heb me nu er toch wel bij neergelegd dat het gebruik van 'this' beter vermeden kan worden, zeker met de komst van AS3 waarbij we weer meer en meer richting Java (en andere echte programmeertalen) gaan. Dus voortaan zal je bij mij ook weinig 'this' meer zien! :O

[TheDutch]

Some people will obsessively put "this" in front of every method call and frield reference, arguing that it makes it "clearer and more explicit". Don't do it. There's a reason that we use high-level languages: They do things for us. If you put 'this' in when it's not necessary, you will confuse and annoy evryone who reads your code, since all the rest of the code they've read won't use this evrywhere. Following a consistent and straightforward coding style saves time and money
Dus wanneer een aantal programmeurs duidelijkheid en expliciteit overbodig vinden moet iedereen dat maar overbodig vinden omdat anders andere programmeurs gaan huilen? Ik vind het een beetje een rare statement van deze "Java Guru".

We mogen dan wel gebruik maken van een high-level programmeer taal die veel dingen voor ons uit handen neemt, maar het moet ons niet lui maken en onze code al helemaal niet foutgevoeliger maken. Wanneer "this" op een goede manier wordt toegepast is er niets mis mee en kan het de code alleen maar ten goede komen.

Scoping - want dat is het gebruik van "this" - is ontzettend belangrijk wanneer je OOP programmeerd. Dit voorkomt fouten en maakt de code een stuk inzichtelijker/duidelijker. Dat je hier wat meer tijd aan kwijt bent is het kostenplaatje voor naar mijn idee goede code. Het is kwaliteit of kwantiteit en ik ga voor kwaliteit. Dezelfde discussie kunnen we hebben over code becommentariëren. Veel argumenten zijn dat dit veel tijd kost en dus geld net zoals Bruce hierboven zegt dat scopen veel tijd en geld kost. Maar goed becommentarieërde code geeft uiteindelijk tijdwinst wanneer een applicatie uitgebreid moet worden. Zo zie ik het ook met scoping.

Wanneer gebruik ik "this"?:
1. Wanneer ik naar de class properties refereer binnen de class.
2. Wanneer ik een class method binnen een class wil aanroepen. Dus ook binnen de built-in classes van ActionScript, bijvoorbeeld: this.createEmptyMovieClip(); of this.onEnterFrame();.
3. Wanneer ik naar een object properties refereer binnen het object, bijvoorbeeld: this._x; of this._alpha;.

Class voorbeeld (punten 1 en 2):

class Test{
// Class properties
var instanceVar1:String = "bla1";
var instanceVar2:String = "bla2";
var instanceVar3:String = "bla3";

var instanceArray:Array = new Array();

// Constructor method
public function Test(){}

// Method that outputs the strings and executes the function popArray()
public function outputStrings():Void{
trace(this.instanceVar1);
trace(this.instanceVar2);
trace(this.instanceVar3);
this.popArray();
}

// Method that outputs a specific string and executes the function popArray()
public function outputString(nr:Number):Void{
trace(this["instanceVar"+nr]);
this.popArray();
}

// Method that populates the array
private function popArray():Void{
this.instanceArray.push("item1");
this.instanceArray.push("item2");
this.instanceArray.push("item3");
}
}

Object voorbeeld (punt 3):

this.onEnterFrame = function(){
this._x += 5;
}

instaneNaam.onEnterFrame = function(){
this._alpha += 5;
}

this._lockroot = true;

Mijn conclusie is dat het gebruik van "this" eigenlijk best wel goed is wanneer het goed gebruikt wordt. Maar dat is eigenlijk met alles zo ;).

[Tha Narie]

this zorgt ook voor een onderscheid tussen lokale (functie) variables en object (this) variables.

[TheZwier]

ik gebruik this bijna altijd, vind het wel handig :) Ik werk ook heel vaak met variabele die aan een mc gekoppeld zijn, en dan werkt this wel zo overzichtelijk... vind ik.

Het is nog wel zo dat ik regelmatig codes op mc`s zelf plaats... *schaam*

[TheDutch]

Precies, wat het op zijn beurt weer duidelijker en minder foutgevoelig maakt :).

[oh,when?]

...Het is kwaliteit of kwantiteit en ik ga voor kwaliteit. Dezelfde discussie kunnen we hebben over code becommentariëren. Veel argumenten zijn dat dit veel tijd kost en dus geld net zoals Bruce hierboven zegt dat scopen veel tijd en geld kost. Maar goed becommentarieërde code geeft uiteindelijk tijdwinst wanneer een applicatie uitgebreid moet worden. Zo zie ik het ook met scoping...

<flauw>Zorg er dan als eerste voor dat je code geen compile errors geeft ;)</flauw>

[TheDutch]

<flauw>Zorg er dan als eerste voor dat je code geen compile errors geeft ;)</flauw>
Hahaha, flauw maar wel scherp :D.
Er zat inderdaad een type fout en een copy/paste fout in. Opgelost! :P.

[TheDutch]

Nog even een toevoeging aangezien ik de laatste dagen wat ben gaan nadenken over deze discussie en ben gaan kijken wat er zoal gebruikt wordt.

Persoonlijk ben ik nog steeds een voorstander voor het "this" gebruik zoals ik dat hierboven omschreef. Echter ben ik een andere manier tegen gekomen wat de code even overzichtelijk maakt of misschien zelfs overzichtelijker.

Class instance variable hebben een _ als prefix en private methods hebben __ als prefix :).

Class voorbeeld:

class Test{
// Class properties
var _instanceVar1:String = "bla1";
var _instanceVar2:String = "bla2";
var _instanceVar3:String = "bla3";

var _instanceArray:Array = new Array();

// Constructor method
public function Test(){}

// Method that outputs the strings and executes the function popArray()
public function outputStrings():Void{
trace(_instanceVar1);
trace(_instanceVar2);
trace(_instanceVar3);
__popArray();
}

// Method that outputs a specific string and executes the function popArray()
public function outputString(nr:Number):Void{
trace(this["_instanceVar"+nr]);
__popArray();
}

// Method that populates the array
private function __popArray():Void{
_instanceArray.push("item1");
_instanceArray.push("item2");
_instanceArray.push("item3");
}
}

[Tha Narie]

Wat jij zegt(bedoelt) klopt volgens mij niet helemaal.
Class variables zijn 'static' ipv 'private'. Jij zegt class-, maar je bedoelt private-.

En zet dan in ieder geval even 'private var' neer ipv 'var' ;)

Leuk en aardig dit, maar dat lost het 'this'-probleem nog niet op. Want private props/methods kan je ook met en zonder 'this' aanroepen.
Wat je hier doet is onderscheid maken tussen public en private.

Verschil tussen properties (_) en methods (__) vind ik ook zinloos, functies spreek je altijd aan met () erachter, dus weet je al dat het een functie is.

[Folkert]

Verschil tussen properties (_) en methods (__) vind ik ook zinloos, functies spreek je altijd aan met () erachter, dus weet je al dat het een functie is.

Daarnaast is het al een beetje zo dat wanneer je de _ of de __ gebruikt dat je deze dan gebruikt om ofwel private class vars aan te geven __privateClassVar ofwel local vars _localVar.
b.v.

function get mijnValue():String
{
return __mijnValue;
}
function set mijnValue( txt:String ):Void
{
__mijnValue = txt;
}

Maar goed dat even terzijde ;)

[TheDutch]

Folkert, dat is ook precies wat ik bedoelde. Op die manier weet je wat local vars zijn en heb je dus een verschil tussen local en method vars, dat is toch wat we wilde? Ditzelfde geldt voor private class vars en methods, het makkelijk kunnen zien wat alleen binnen de class is en wat ook vanaf buiten benaderd kan worden.

Aangezien methods eigenlijk alleen maar in een class voorkomen wanneer je 100% OOP programeert, heb je "this" dus niet nodig om class methods en reguliere functies te onderscheiden.

Naar mijn idee is op deze manier voor vele het "this" probleem opgelost :)

Hier trouwens een goede Code Guidelines (http://geosoft.no/development/javastyle.html). Weliswaar voor Java opgesteld, maar goed toe te passen bij elke taal. Jammer alleen is dat wanneer je dit exact opvolgt je weer het "this" probleem creert.

@Tha Narie: Er stond class variables, maar ik bedoelde class instance variables. Dit heb ik overigens al 5 minuten voor jouw bericht aangepast. Ook was mijn opzet niet om onderscheid te maken tussen properties en methods ;).

[rinde]

wat ik nu al een ruim een half jaar gebruik is simpelweg een letter die de scope aangeeft voor elke varibele zetten:



class Example
{
// f staat voor file, een globale variabele die in de hele file beschikbaar is.
private var fGlobalVar:Number;

// p staat voor parameter
private function execute( pTimes:Number ) : Void
{
fGlobalVar = pTimes;

// l staat voor local
var lOnzin:String = fGlobalVar + " dusss";

// bullshit:
execute( fGlobalVar );
}

}


het is heel even (+-uurtje) wennen, maar dan wil je ook niks anders meer :)

[Tha Narie]

En hoe noem je public vars dan? En static vars?

En aan die 'f' heb je straks in AS3.0 ook niets meer, want dan kan je meerdere classes in 1 file(package) zetten.

En om een private var nou met een globale var te vergelijken vind ik ook een beetje vreemd ;)

[TheDutch]

Tha Narie, wanneer kom jezelf eens met een goed idee?

[rinde]

En hoe noem je public vars dan? En static vars?

En aan die 'f' heb je straks in AS3.0 ook niets meer, want dan kan je meerdere classes in 1 file(package) zetten.

En om een private var nou met een globale var te vergelijken vind ik ook een beetje vreemd ;)

met file bedoel ik ook meer de class waar het in staat, als je meerdere classes in 1 file zet, is dat verder geen probleem. Deze 'conventie' komt oorspronkelijk uit java geloof ik, en daar worden alle classes natuurlijk automatisch een aparte file.. vandaar de f.

Ik maak verder geen onderscheid tussen public/private/static vars, globaal was een beetje verkeerd gekozen geloof ik.

[Tha Narie]

Tha Narie, wanneer kom jezelf eens met een goed idee?
Zodra ik iets heb gevonden wat echt goed is, zonder haken en ogen ;)

Deze 'conventie' komt oorspronkelijk uit java geloof ik, en daar worden alle classes natuurlijk automatisch een aparte file.. vandaar de f.
Nope, in Java kan je meerdere classes in 1 file zetten, wat je straks dus in AS3.0 ook kunt doen :)

Ik maak verder geen onderscheid tussen public/private/static vars
Betekent dat dat je public vars ook met een f begint? Dat zou dan niet kloppen, want die zijn buiten de file beschikbaar ;)
Als je die niet met een f begint, maak je wel een onderscheid, zou iets beter kloppen :P

[TrueChaoZ]

Als je die niet met een f begint, maak je wel een onderscheid, zou iets beter kloppen :PEn in AS3 heb je hiervoor 'internal' dus is dat toch nergens voor nodig ;)

[rinde]

Nope, in Java kan je meerdere classes in 1 file zetten, wat je straks dus in AS3.0 ook kunt doen :)


hehe, laat ik me nog iets duidelijker uitdrukken: als je een java file (.java) met meerdere classes erin compiled, maakt ie automatisch voor iedere class een aparte file (.class) aan. Wat bij AS2.0/3.0 anders is, er gaan meerdere classes in 1 swf.


Betekent dat dat je public vars ook met een f begint? Dat zou dan niet kloppen, want die zijn buiten de file beschikbaar
Als je die niet met een f begint, maak je wel een onderscheid, zou iets beter kloppen :P


deze conventie gebruik ik alleen binnen een class, het is idd waar dat f eigenlijk niet voor een public var hoort te staan, als je de regels heel strict naleefd.
Ik probeer het direct aanroepen van vars in andere classes zoveel mogelijk te beperken, en vooral via functies data uit te wisselen. Daarom zijn bijna al mijn vars private. En als ik toch iets direct moet aanroepen, maak ik inderdaad wel eens een uitzondering. Maar dan nog niet altijd, omdat de duidelijkheid binnen de class daar minder van wordt.

Binnen de class maakt het niet uit of de var public/private is, je ziet gewoon in 1 oogopslag wat de scope van een var is.

[TheDutch]

Voor mij is de kous af, ik gebruik "this" zoals ik dit altijd al deed (http://www.flashfocus.nl/forum/showpost.php?p=47122&postcount=19). Ik heb "Using scope" (http://livedocs.macromedia.com/flash/mx2004/main_7_2/wwhelp/wwhimpl/common/html/wwhelp.htm?context=Flash_MX_2004&file=00000846.html) gelezen van de LiveDocs van Macromedia:

Using the this keyword

Whenever possible, use the this keyword as a prefix instead of omitting the keyword, even if your code works without it. You can use the this keyword to learn when a method or property belongs to a particular class. For example, for a function on the main Timeline, write ActionScript using the following format:

circle_mc.onPress = function() {
this.startDrag();
};
circle_mc.onRelease = function() {
this.stopDrag();
};

For a class, you can write code in the following format:

class User {
private var m_username:String;
private var m_password:String;
function User(username:String, password:String) {
this.m_username = username;
this.m_password = password;
}
public function get username():String {
return this.m_username;
}
public function set username(username:String):Void {
this.m_username = username;
}
}

If you consistently add the this keyword in these situations, your ActionScript will be much easier to read and understand.

Ze geven precies dezelfde punten aan als ik die aangaf in mijn eerst antwoord op dit onderwerp (http://www.flashfocus.nl/forum/showpost.php?p=47122&postcount=19). Zegt voor mij genoeg :).

[Roenes]

Uiteindelijk denk ik dat het niet zo heel veel uitmaakt wat je beslist. In eerste instantie moet je voor jezelf een standaard kiezen en die ook consistent naleven. Als je daarna met meer mensen aan 1 project gaat werken, zul je met die groep regels moeten afspreken. Of dit nou al bestaande conventies zijn, of eigen gemaakte conventies, dat maakt niet uit.

Zolang je maar strict naleeft wat je met je projectgenoten vastlegt is er geen probleem :)

[Folkert]

Of dit nou al bestaande conventies zijn, of eigen gemaakte conventies, dat maakt niet uit.

Zolang je maar strict naleeft wat je met je projectgenoten vastlegt is er geen probleem :)
Sja daar ben ik het niet helemaal mee eens.
Wanneer je gaat kiezen voor een manier van schrijven (waar daar gaat het hier om), dan is het toch handigst om bestaande 'standards' op te pikken dan dat je een setje creaNamen moet gaan aanwennen die toevallig binnen een project gelden.

Maar goed de discussie hoorde op zich wel gewoon over wel of niet gebruik van 'this'

;)