[Discussie] get set methods

[theFlashWizard]

Inleiding
Beste Developers,
In de post EAS 3.0 Now Shipping (http://www.flashfocus.nl/forum/showthread.php?p=272438) was stiekem al een kleine discussie aan de gang over getters setters methods.
Ik heb op dit moment een voorkeur voor de automatische get set methods van ActionScript.
Terwijl onder andere Colin Moock en Dauntless getProperty() en setPropery() preveren.

Ik wou in dit topic de voor en nadelen van beide vormen bespreken.
Zo hoop ik straks een goede keuze te maken, want waarom zou ik geen ongelijk hebben :)

Erg jammer is overigens dat er in eas3 alleen wordt gezegd dat het een kwestie van smaak is.

Ik zal nu voor zo ver ik ze weet de voor en nadelen van beide manieren opnoemen.

getPropery setProperty methods
Voordelen

Sneller overzicht over read en write mogelijkheden. (Wel aan api te zien)
Kan niet verward worden met gewone public variabele.
Is sneller. Bijna net zo snel reguliere property opvragen.

Nadelen

Onprettig in bijv. formules vanwege hun syntax
ActionScript 3.0 maakt niet vaak gebruik van. (Dus dat maakt je script minder consistent met de built-in ActionScript Classes)
Staan ver van elkaar af in bijv. code hints.
ASDocs kan niet automatisch zien of het read-only is.
Het is verwarrend als je alleen een getPrivate public maakt.
Langere (dus minder snelle) syntax
Je kan geen gebruik maken van bijv ++ en --.

Automatische get set methods
Voordelen

Prettig in bijv. formules vanwege hun syntax
ActionScript 3.0 maakt er vaak gebruik van. (Bijv. x, y properties) (Dus dat maakt je script consistenter met de built-in ActionScript Classes).
Worden gebundeld in 1 waarde. setProperty en getProperty staan ver van elkaar af in bijv. code hints.
ASDocs kan automatisch zien of het read-only is.
Je kan zonder verwarring de Set private kan maken en de Get public. Wanneer je dit doet met getProperty en setProperty kan het verwarrend werken aangezien je bij een getProperty ook een setProperty verwacht.
Kortere (dus snellere) syntax.
Je kan gebruik maken van bijv ++ en --.

Nadelen

Minder snel overzicht over read en write mogelijkheden. (Niet aan api te zien) (Wel in documentatie van ASDoc)
Kan verward worden met gewone public variabele.
Is langzamer.


Conclusie
Vul ik in na de discussie.



Nu is de vraag aan jullie wat jullie mening is en wat jullie kunnen bijdragen aan deze lijst.

Alvast bedankt

[matzo]

Hey tFW, een paar opmerkingen. Zelf prefereer ik eigenlijk ook 'get and setters' hoor;). Alleen wou ik even antwoorden waarom Moock getProperty en setProperty zou kunnen prefereren.
Verder, als je api-docs maakt met ASDoc van adobe, dan wordt een variable die alleen met een getter gedefinieerd is, gemarkeerd als read-only.
Alleen kun je het bij code hinting in FD(geen ervaring met andere editors behalve sepy) niet zien, net zoals je dat niet kunt bij movieclip.parent.(Misschien eens doorgeven aan het FD development team als feature?) Ook geeft adobe niet de 'property is read-only' fout, maar de minder zeggende 'possibly undefined property'.

Verder, leuk topic, alleen weet ik niet of de conclusie eigenlijk niet hetzelfde gaat zijn als die van moock('Het is een kwestie van smaak'). Je smaak is natuurlijk heel wat makkelijker te vinden als je de voor en nadelen op een rijtje hebt, maar ik denk dat dit lijstje al redelijk volledig is...:)

[Dauntless]

Uiteindelijk is het gewoon smaak ja :).

Waarom ik het prefereer? Het voelt gewoon prettiger aan dat ik een property via een duidelijke functie benader, in plaats van dat de kans bestaat dat ik iets fout doe.

Bv: Iemand schrijft een public library, maar hij heeft de slechte gewoonte om al z'n variabelen public te maken. Dan vraag je je toch bij elke property af of je die wel mag accessen. Als er aan de andere kant een getProp/setProp is, dan weet je dat er niets mis zal gaan.

[theFlashWizard]

Ow sorry matzo, verkeerd begrepen, heb het bovenaan verandert. Heb ook je ASDoc opmerking meegenomen.
maar ik denk dat dit lijstje al redelijk volledig is...
Dat maakt deze discussie wel erg saai dan :|

Dauntless, dat is in sommige gevallen idd een punt. Ik zet hem erbij :)

[TheDutch]

Interessante discussie! :)

Aangezien ik morgenochtend weer om 6uur op moet ga ik het nu niet meer redden om er uitgebreid op te reageren. Graag zal ik morgenavond mijn visie op dit discussiepunt geven. Bij deze in elk geval alvast mijn blijk van interesse.

[matzo]

Ook wel passend in deze discussie:
Als je in een formule in een class een variable gebruikt die een getter en setter heeft, of een getProperty/setProperty, welke access-manier zouden jullie dan gebruiken.

package {

public class TempScale{
private var _fahr:Number;

public function TempScale(){
}

public function calculateCelcius():Number{
return (5/9*(this._fahr-32));
}

public function get fahrenheit():Number{
return this._fahr;
}
public function set fahrenheit(value:Number){
if(value<100){
this._fahr = value;
}
}
}
}

return (5/9*(this._fahr-32));
Wat zouden jullie gebruiken in deze regel? this.fahrenheit/this.getFahrenheit(), of this._fahr.
This.fahrenheit/this.getFahrenheit() heeft zijn voordelen hier, lijkt me, want de naam van een getter of setter zou nooit mogen veranderen, terwijl de interne variabele wel eens later van naam zou kunnen veranderen.

[theFlashWizard]

Interessante matzo ;)
Mijn voorkeur:
return (5/9*(this.fahrenheit-32));
Dit omdat je dan ook eventuele extra dingen die in een get uitgevoerd worden meeneemt.
Stel dat je public getter setter niet eens een private variant hebt, maar dat die deze variabele uitrekent. Dan moet je wel een getter gebruiken. Dus ik denk dat je op die manier consequenter kan zijn.
Ook ben ik het met je eens dat je meer zekerheid hebt zo, want idd, de api zou eigenlijk nooit mogen veranderen.

De enigste uitzondering voor mij is, wanneer preformance een grote rol speelt (mogelijk in game, in een loop bijv.) dan zou ik de private var aanspreken, dit scheelt dan namelijk wat method calls.

Voor de rest gebruik ik altijd this omdat ik dan codehints krijg in flashdevelop wat mijn typo's sterk vermindert.

[matzo]

Interessante matzo ;)
Mijn voorkeur:
return (5/9*(this.fahrenheit-32));
1)Dit omdat je dan ook eventuele extra dingen die in een get uitgevoerd worden meeneemt.

2)Stel dat je public getter setter niet eens een private variant hebt, maar dat die deze variabele uitrekent. Dan moet je wel een getter gebruiken. Dus ik denk dat je op die manier consequenter kan zijn.

3)Ook ben ik het met je eens dat je meer zekerheid hebt zo, want idd, de api zou eigenlijk nooit mogen veranderen.

De enigste uitzondering voor mij is, wanneer preformance een grote rol speelt (mogelijk in game, in een loop bijv.) dan zou ik de private var aanspreken, dit scheelt dan namelijk wat method calls.

Voor de rest gebruik ik altijd this omdat ik dan codehints krijg in flashdevelop wat mijn typo's sterk vermindert.

1) Ja, maar dit kan ook juist een probleem zijn:) Stel dat je bijvoorbeeld intern alles in Kelvin doet, zodat je berekeningen met het absolute nulpunt makkelijk kunt uitvoeren, of omdat je iets met thermodynamische processen moet doen(waarbij je altijd kelvin moet gebruiken). Maar vanwege gebruiksgemak laat je de gebruiker alles invoeren en terugkrijgen in Celcius, en reken je het in de getter van kelvin naar celcius om, en in de setter van celcius naar kelvin. Dan kun je dus best de private var gebruiken.

2)Je zou natuurlijk die omrekening ook kunnen gebruiken in de formule, maar we weten allemaal dat dat stom is, en geen fatsoenlijk argument is;):P
Consequent zijn is natuurlijk wel mooi, maar in het geval dat ik bij 1 schets kun je ook niet anders dan de private variant gebruiken. Dus écht altijd consequent zijn zou soms ook maar rare code opleveren ...:)

De extra zekerheid is nog het grootste voordeel voor mij, veel van de keren zou het veranderen van de private naam geen probleem opleveren, omdat je gewoon find&replace gebruikt, maar wanneer het wel een probleem oplevert, is het een héél irritante fout.:)

Ik gebruik trouwens ook altijd this, om dezelfde rede, en het is handig als je iets moet zoeken, om er this voor te zetten. Verder zie ik ook liever this.fahrenheit in dat voorbeeldje, al is het voor mij nog geen automatisme:). Vroeger zou ik altijd this._fahr gebruikt hebben.

En natuurlijk ook nog even opmerken dat je nu ook niet om de haverklap van private variabelenaam moet veranderen:D.

(Misschien is het wel de moeite deze discussie af te splitsen?)

[theFlashWizard]

1) Je bedoelt dan dat je de in een celcius getter, kelvin omrekent naar celius neem ik aan?
Dan moet je inderdaad wel de private gebruiken. Maja, ik zie het punt niet helemaal hiervan.
In as2.0 kon je geen private getters en setters maken (volgens mij) nu met as3.0 is dat voorbij.

2) Ook hierbij volg ik je niet helemaal. Waarom geen private getter, setter?
Een private getter en setter lijkt mij persoonlijk dan weer wat overdreven, maar het zou kunnen.
Ik persoonlijk zou wanneer ze niet in de api zitten de private var's direct gebruiken.
Whaha nog een discussie, waarom zou je een private getter/setter maken ;)

Spliten is een idee :) Dan zou een moderator de posts na #5 moeten verplaatsen en dan zou jij post #6 een klein beetje moeten aanpassen :)
Geen flauw idee hoe je zoiets aanvraagt P)

[BernardV]

Leuke discussie :)

Er zijn eigenlijk 3 dingen die je public kunt maken in flash, variabelen, properties en functies.
Nu is het zo dat variabelen en properties voor de gebruiker van de class niet uitmaken, immers zal deze alleen zien class.naam of het nu een getter/setter is of een public var.
Getters en setters zijn in mijn ogen dan ook alleen gunstig als je een bepaalde controle wilt uitoefenen iets als:

private var __description:String = "";
//....
public function set description(desc:String):void
{
if(desc.length>0) __description = desc;
}
Als je getters en setters alleen gebruikt om een private var te lezen en te schrijven kun je net zo goed de var public maken, immers maakt dat niet uit.
Een getter kan ook handig zijn voor read-only properties (zoals bv length bij String).

Zelfde idee heb ik ook bij getProperty() functies, als deze alleen gebruikt worden voor lezen en schrijven dan zijn ze overbodig en kosten alleen maar ruimte en CPU tijd.

[TheDutch]

Waar gaat het over?

Optie 1 (Get / Set):

private var _name:String;

public function get name():String
{
return this._name;
}

public function set name(value:String):void
{
this._name = value;
}



Optie 2 (getProperty / setProperty):

private var _name:String;

public function getName():String
{
return this._name;
}

public function setName(value:String):void
{
this._name = value;
}


Ik gebruik niet één van deze twee, maar allebei in verschillende situaties :).

Ik gebruik optie 1:

Wanneer het om het getten en setten van een property gaat met één argument en dat is de waarde.
Omdat je dan één manier hebt om de waarde op te halen en toe te wijzen, in plaats van twee verschillende functies die niet eens onder elkaar in de code completion staan.
Omdat ASDocs wanneer een set of get ontbreekt het herkent als een "read-only" of "write-only" variable en dat snel kan laten zien in de documentatie.
Omdat je zonder verwarring de Set private kan maken en de Get public. Wanneer je dit doet met getProperty en setProperty kan het verwarrend werken aangezien je bij een getProperty ook een setProperty verwacht.
Omdat een Set ook de waarde (intern met Get) weer teruggeeft en dus makkelijk bij formules gebruikt kan worden. Dit kan ook met een setProperty maar dan moet je zelf zorgen voor een return waarde wat niet hoeft met een Set.
Omdat een prefix voor de property naam code completion vertraagt. Je moet altijd eerst "set" of "get" intypen alvorens je met de werkelijke property naam kan gaan beginnen.
Omdat je met een Set heel makkelijk ++ of -- bij een nummer kunt gebruiken. Bij een setProperty moet je dit doen setProperty(getProperty()+1).

Ik gebruik optie 2:

Wanneer snelheid belangrijk is. setProperty(getProperty()+1) kan namelijk een heel stuk sneller zijn dan Set++, vooral met bindings.

Wanneer het om het setten van een property gaat met meer dan één argument.

Wanneer de getProperry alleen zijn (nieuwe) waarde mag broadcasten aan zijn binding wanneer ik de opgegeven event type dispatch. Dus handmatige controle over de binding in plaats van een automatische binding.

Wanneer ik de property in een andere scope wil veranderen dan waar de property zich in bevindt. Wanneer je de property neergezet met Get / Set meegeeft aan een functie als argument zal het wijzigen van de waarde alleen van toepassing zijn op de parameter van die functie en niet de werkelijke property. Wanneer je een setProperty functie als functie meegeeft aan een functie dan kan je die later gebruiken om de werkelijke property in die andere scope te setten.


Zoals je ziet kan het per geval nog al eens verschillen welke techniek je gebruikt. Mijn voorkeur gaat echter wel uit naar optie 1 en pak optie 2 alleen aan wanneer ik die echt nodig heb :).

// EDIT: Het gebruik van getters en setters (zowel Get / Set als getProperty / setProperty) is natuurlijk alleen nodig wanneer het meer moet doen dan dan simpel de waarde setten en teruggeven. Verder kunnen getters en setters handig zijn wanneer je veel met Interfaces werkt omdat getters en setters als properties wel in een Interface kunnen staan terwijl reguliere properties dat niet kunnen, dit omdat in een Interface alleen methods mogen staan. Ook kan je in tegenstelling tot reguliere properties de getters en setters van een superclass - mits in de juiste namespace (public, protected) - overriden zoals je dit ook kunt doen met een method.

[TheDutch]

Zelfde idee heb ik ook bij getProperty() functies, als deze alleen gebruikt worden voor lezen en schrijven dan zijn ze overbodig en kosten alleen maar ruimte en CPU tijd.
Toch niet helemaal. Zie mijn vorige reactie optie 2 > punt 1 :).

[BernardV]

Toch niet helemaal. Zie mijn vorige reactie optie 2 > punt 1 :).
Toch wel, want dit gaat alleen op als je get en set maakt, als je gewoon een public var hebt is dat sneller.

//EDIT voorbeeld:

package
{
public class Tester
{
public var testValue:Number = 0;
private var __testValue2:Number = 0;
private var __testValue3:Number = 0;

public function Tester(){}

public function getTestValue2():Number
{
return __testValue2;
}

public function setTestValue2(value:Number):void
{
__testValue2 = value;
}

public function get testValue3():Number
{
return __testValue3;
}

public function set testValue3(value:Number):void
{
__testValue3 = value;
}
}
}

Draai het zo:

package {
import flash.display.Sprite;
import flash.utils.getTimer;

[SWF(width="300", height="200", frameRate="31", backgroundColor="#000000", encoding="utf-8")]

public class SoundVisual extends Sprite
{
public function SoundVisual()
{
var t:Tester = new Tester();
var start:Number = getTimer();
while(t.testValue<1000000){
t.testValue++;
}
trace("Public var:",getTimer()-start);

var t2:Tester = new Tester();
var start2:Number = getTimer();
while(t2.getTestValue2()<1000000){
t2.setTestValue2(t2.getTestValue2()+1);
}
trace("getProperty function:",getTimer()-start2);

var t3:Tester = new Tester();
var start3:Number = getTimer();
while(t3.testValue3<1000000){
t3.testValue3++;
}
trace("getter/setter:",getTimer()-start3);
}
}
}

Dan is het resultaat hier:

Public var: 105
getProperty function: 1074
getter/setter: 1113

Dat getProperty sneller is dan een getter setter is hier ook zichtbaar, alleen geen 30% in dit geval, maar als je dit niet nodig hebt is een public var VEEEL sneller.

//PS. SoundVisual was het eerste project wat ik vond waar nog niets in aanwezig was, dus let niet op die naam :P

[TheDutch]

Dat is niet waar wat je zegt :).

setProperty(getProperty()+1) is +/- 10% sneller dan "_property = _property+1".
setProperty(getProperty()+1) is even snel als "_property++".
setProperty(getProperty()+1) is +/- 30% sneller dan "(set) property++".
getProperty() is even snel als "_property".

Lees mijn punt 1 bij optie 2 nog maar eens goed door en doe zelf de test (FOR loop 1000x met msec verschil tussen start en eind).

[BernardV]

Zie mijn vorige post..

[matzo]

1) Je bedoelt dan dat je de in een celcius getter, kelvin omrekent naar celius neem ik aan?
Dan moet je inderdaad wel de private gebruiken. Maja, ik zie het punt niet helemaal hiervan.
In as2.0 kon je geen private getters en setters maken (volgens mij) nu met as3.0 is dat voorbij.

2) Ook hierbij volg ik je niet helemaal. Waarom geen private getter, setter?
Een private getter en setter lijkt mij persoonlijk dan weer wat overdreven, maar het zou kunnen.
Ik persoonlijk zou wanneer ze niet in de api zitten de private var's direct gebruiken.
Whaha nog een discussie, waarom zou je een private getter/setter maken ;)

Spliten is een idee :) Dan zou een moderator de posts na #5 moeten verplaatsen en dan zou jij post #6 een klein beetje moeten aanpassen :)
Geen flauw idee hoe je zoiets aanvraagt P)
Ik snap niet waar jij uit mijn post private getters en private setters vandaan haalt.

Ik bedoel bij 1:

package {

public class IsobaarProces{
private var _kelvin:Number;
public var volume:Number;

public function IsobaarProces(){
}
/**
* Calculates the new volume after de/increasing your temperature to the given value
* @see http://nl.wikipedia.org/wiki/Wet_van_Gay-Lussac
*/
public function calculateVolume(p_temperature:Number){
return this.volume*(p_temperature-273,15)/this._kelvin;
/*variant met gebruik van getter en setter intern:
return (this.volume*(p_temperature-273,15)/(this.temperature-273,15);
Dit is langer, maar niet zóveel langer. Maar je zou hetzelfde kunnen hebben in een class voor 3d.
Hier zou je dan de invoer laten gebeuren in graden, maar alles flash wil zelf alles radialen. Dus kun je het in graden opslaan in een variabele graden die je public maakt, en zelf bij iedere call naar Math.sin(), Math.cos(), enz omrekenen.
Je zou echter ook getters and setters kunnen maken, voor een variabele graden, en daar omrekenen naar radialen, en dit opslaan in een private var radialen. Als je echter dan altijd in Math.sin de getters zou gebruiken, ben je eigenlijk niks verder:)
*/
}

/**
* Temperature in Celcius
*/
public function get temperature():Number{
return this._Kelvin+273,15;
}

public function set temperature(value:Number){
this._Kelvin = value-273,15;
}

public
}
}

Bij 2 is de eerste zin een grap. Als je in je getters de variabele moet uitrekenen, kun je dat in je formule ook, zeg ik;). Natuurlijk gaan we dat niet doen, omdat als je die formule vaak moet gebruiken, het de kans op fouten vergroot.

Verder in 2 zeg ik gewoon dat hierin helemaal consequent zijn, moeilijk is.

Je zou echter intern ook je getters en setters willen gebruiken, omdat iemand die aan jou class moet werken, niet moet zoeken hoe je private variabele in elkaar zit, maar gewoon de api even moet lezen:).

En theDutch, bij de voordelen van optie een:
Omdat ASDocs - wanneer een set ontbreekt - herkent dat het een "read-only" variable is en dat snel kan laten zien in de documentatie.
En als er een get ontbreekt, herkent dat het een write-only variable is, en dat snel kan laten zien in de documentatie.
(Gewoon voor de volledigheid toevoegen?;))
Ik ga zoeken waar ik kan vragen of een mod het even splitst:)

[TheDutch]

Zie mijn vorige post..
Ik heb ze nu ook in een FOR loop 1000000x uitgevoerd 3 maal en krijg deze resultaten:

setProperty(getProperty()+1)
7345
7064
7002

property++
14479
14044
14230

_property++
6479
6431
6441

Je ziet dat property++ (get en set) hier zelfs +/- 50% langzamer is dan setProperty(getProperty()+1). Met 1000000x zijn _property++ en property++ niet gelijk aan elkaar maar het scheelt niet veel. Echter bij 1000x zijn ze dat bij mij wel. Ik gebruik een FOR loop jij een WHILE dat kan ook wellicht nog wat schelen.

Conclusie is voor mij in elk geval dat Set / Get overduidelijk de langzaamste is. Die andere twee zijn onder de 1000x zo goed als gelijk aan elkaar, daar boven is de gewone property aanroep toch een stukje sneller naarmate het aantal loops hoger worden :).

// EDIT: Mijn resultaten zijn met bindings aan(!). Zonder de bindings heb ik ongeveer dezelfde uitkomst als jij.
// EDIT2: Ik heb mijn puntenlijst aangepast wat betreft de snelheid.

[BernardV]

Mag ik je code eens zien?
Inderdaad is een for loop sneller maar het verschil tussen public en de andere opties blijft redelijk gelijk bij me.

Snelste wat ik krijg is:

Public var: 110
getProperty function: 764
getter/setter: 790

Met een loop als:
for(var i:Number = 1000000;i-->0;){//code}

[TheDutch]

En theDutch, bij de voordelen van optie een:

En als er een get ontbreekt, herkent dat het een write-only variable is, en dat snel kan laten zien in de documentatie.
(Gewoon voor de volledigheid toevoegen?;))
Thanks man! Toegevoegd :).

[TheDutch]

Mag ik je code eens zien?

Natuurlijk! :)


<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">

<mx:Script>
<![CDATA[
import flash.utils.getTimer;

private var _nummer:Number = 0;


public function get nummer():Number
{
return _nummer;
}

public function set nummer(value:Number):void
{
_nummer = value;
}


public function getNummer():Number
{
return _nummer;
}

public function setNummer(value:Number):void
{
_nummer = value;
}

private function test():void
{
var begin:Number = 0;
var eind:Number = 0;

begin = getTimer();
for(var i:int=0;i<1000000;i++)
{
_nummer++;
}
eind = getTimer();
trace("Public var: "+String(eind-begin));

begin = getTimer();
for(var i:int=0;i<1000000;i++)
{
setNummer(getNummer()+1);
}
eind = getTimer();
trace("getProperty function: "+String(eind-begin));

begin = getTimer();
for(var i:int=0;i<1000000;i++)
{
nummer++;
}
eind = getTimer();
trace("getter/setter: "+String(eind-begin));


}
]]>
</mx:Script>

<mx:HBox width="100%">
<mx:Button label="Klik!" click="test()" />
</mx:HBox>




</mx:Application>

[BernardV]

Als ik je code 5x achter elkaar draai heb ik dit:

Public var: 93
getProperty function: 719
getter/setter: 719
Public var: 94
getProperty function: 734
getter/setter: 750
Public var: 94
getProperty function: 734
getter/setter: 750
Public var: 94
getProperty function: 750
getter/setter: 750
Public var: 94
getProperty function: 750
getter/setter: 750

Toch raar dat we zo'n verschil hebben :S

[TheDutch]

Mijn resultaat in post #17 was met bindings. Dit is zonder :).

ps. Ik heb new Date().getTime() weer vervangen door getTimer(). Was wat aan het proberen en dat had ik per ongeluk mee gekopieerd.

// EDIT: Mijn resultaat is nu:
Public var: 96
getProperty function: 758
getter/setter: 821
Public var: 99
getProperty function: 741
getter/setter: 757
Public var: 199
getProperty function: 788
getter/setter: 917
Public var: 100
getProperty function: 829
getter/setter: 820
Public var: 96
getProperty function: 817
getter/setter: 791

[theFlashWizard]

Bernard,
Zelfde idee heb ik ook bij getProperty() functies, als deze alleen gebruikt worden voor lezen en schrijven dan zijn ze overbodig en kosten alleen maar ruimte en CPU tijd.
Zijn getProperty(), setPropery() functies dan langzamer dan automatische getters / setters ?

theDutch,
Goede punten :) Ik heb ze boven weer bijgewerkt.
Enig idee hoe het komt dat zo'n getProperty zoveel sneller is? Kan me bijna niet voorstellen dat het evensnel is als een reguliere property, het blijft toch een method class?
Ook het scrope verhaal bij punt 2 is me niet helemaal duidelijk.

Bernard & theDutch,
Top dat jullie dit uit proberen te zoeken :)
Wat is dat binding waar jullie het over hebben? Kunnen jullie hier iets meer over vertellen?

Matzo,
Weet niet of ASDoc wel private zaken meeneemt?

[matzo]

@theFlashWizard
Nee, dat neemt ASDoc niet mee. Ik zie alleen niet waar ik dat beweerd heb?
Quasi alles over ASDoc:
http://labs.adobe.com/wiki/index.php/ASDoc:Creating_ASDoc_Comments

[TheDutch]

Wat is dat binding waar jullie het over hebben? Kunnen jullie hier iets meer over vertellen?

Binding is een Flex 2 iets. Je kunt dan waarden van een property aan een andere property binden zodat deze automatisch hetzelfde blijven. Erg krachtige tool in Flex 2 :).


Enig idee hoe het komt dat zo'n getProperty zoveel sneller is? Kan me bijna niet voorstellen dat het evensnel is als een reguliere property, het blijft toch een method class?

Ik heb net weer een andere test (+1 ipv. ++) gedaan die weer zegt dat getter/setter weer sneller is dan getProperty/setProperty. Waarschijnlijk verschilt het heel erg per actie die je doet. Ik hou het erop dat een reguliere property gewoon altijd sneller is en de getter/setter ongeveer gelijk is aan getProperty/setProperty qua executietijd.


Ook het scrope verhaal bij punt 2 is me niet helemaal duidelijk.

Wanneer je een property meegeeft als argument aan een method en je veranderd dat argument binnen de method weer van waarde dan zal het argument alleen van waarde veranderd en niet het property wat in het begin mee was gegeven als argument. Dit geldt dus ook wanneer je getter/setter gebruikt. Echter wanneer je getProperty/setProperty gebruikt kan je setProperty functie als argument meegeven aan de method en die binnen die method (andere scope) uitvoeren. Toch zal de uitgevoerde code binnen setProperty zich in de originele scope bevinden en dus het property aanpassen. Voorbeeld:

Dit werkt
=======
Class 1:

private var _naam:String = "nee";

private function init():void
{
trace(_naam); // nee
class2Instance.geefAanClass2(setNaam);
trace(_naam); // ja
}

public function setNaam(value:String):void
{
this._naam = value;
}


Class 2:

public function geefAanClass2(setNaam:Function):void
{
setNaam("ja");
}


Dit werkt niet!
===========
Class 1:

private var _naam:String = "nee";

private function init():void
{
trace(_naam); // nee
class2Instance.geefAanClass2(naam);
trace(_naam); // nee
}

public function set naam(value:String):void
{
this._naam = value;
}


Class 2:

public function geefAanClass2(naam:String):void
{
naam = "ja";
}


Is het wat duidelijker zo? Probeer anders uit te leggen wat je niet duidelijk is :).

[Tha Narie]

Even paar kleine remarks die me tijdens het lezen te binnen schoten:


bindings werken ook al in AS2, V2 componenten werken ermee.
FlashDevelop 3 heeft een 'search' in autocompletion, dus dan hoef je niet persé get/set of int/arr/str/obj of _ ervoor te typen
Zoals TheDutch goed aan geeft hangt het heel erg af van de situatie (gebruik - arguments = getFunctie, rekenen = getter, snelheid - in games enz liefst public properties, enz)
Ookal wrap je met een getter/setter vaak alleen maar een private property, vaak is het wenselijk om dit toch via een getter/setter te doen zodat je later de functionaliteit of benamingen van je code binnen je class kan aanpassen en de API hetzelfde kan laten.



Waarom ik het prefereer? Het voelt gewoon prettiger aan dat ik een property via een duidelijke functie benader, in plaats van dat de kans bestaat dat ik iets fout doe.

Bv: Iemand schrijft een public library, maar hij heeft de slechte gewoonte om al z'n variabelen public te maken. Dan vraag je je toch bij elke property af of je die wel mag accessen. Als er aan de andere kant een getProp/setProp is, dan weet je dat er niets mis zal gaan.

Dit is natuurlijk een beetje onzin. Je zegt hier dat jij liever g/s-functies gebruikt omdat een ander misschien slordig is in het schrijven van classes.

Het is juist natuurlijker om een propertie als property op te halen, en niet als functie. Doet mij denken aan de F4/5 tijd:
setProperty(mc, '_x', getProperty(mc, '_x') + 5);

In FlashDevelop kan je in de autocompletion sowieso zien of het gaat om een standaard property of een getter/setter property :)

[theFlashWizard]

TheDutch, owke binding is duidelijk :)
Moet later nog maar een keer uitzoeken hoe je dat doet.

Je verhaal van property meegeven als argument begrijp ik grotendeels :)
Al snap ik niet dat je, terwijl er alleen een set is de property kan meegeven.
en... wanneer is dit handig?

Matzo,
Mijn opmerking/vraag kwam voort uit deze opmerking:
Je zou echter intern ook je getters en setters willen gebruiken, omdat iemand die aan jou class moet werken, niet moet zoeken hoe je private variabele in elkaar zit, maar gewoon de api even moet lezen.


Bernard & theDutch,
willen jullie de resultaten van jullie onderzoekje anders nog in 1/2 post(s) verzamelen voor me, ik denk dat de bezoeker van dit topic er dan veel meer aan hebt :)

Tha Narie,
FlashDevelop 3 heeft een 'search' in autocompletion, dus dan hoef je niet persé get/set of int/arr/str/obj of _ ervoor te typen
Om maar even te mieren ******, je moet het nog steeds helemaal schrijven bij het schrijven van de method.

Ik denk ook dat dit in de conclusie gaat doorvloeien, dat het ook aan de situatie ligt :)

Gelukkig heb ik die:
setProperty(mc, '_x', getProperty(mc, '_x') + 5);
eigenlijk nooit meegemaakt ;)

[TheDutch]

Tha Narie,

Dat klopt dat bindings al eerder bestonden. Ik had "Flex 2" neergezet maar eigenlijk had er "Flex" moeten staan.

Ik weet niet of het altijd goed is om uit te gaan van FlashDevelop. Merendeel van de ActionScript programmeurs (buiten MediaMonks!) zal (nog) gewoon in de Flash IDE werken of in Flex Builder. Daar zit die functionaliteit niet in en dus is dit niet echt een heel sterk argument om aan te geven dat g/s-functies net zo makkelijk aan te vullen zijn met code completion als getters en setters. Dat verschilt per IDE en daarom blijft het een nadeel ven g/s-functies, misschien niet voor jou maar wel voor anderen :).

Precies! Mijn properties zijn zo goed als altijd private en gebruik getters en setters om ze zichtbaar te maken in mijn API. Een mooi woord daarvoor is encapsulation (http://www.csharp-station.com/Tutorials/Lesson19.aspx). Dit zorgt ervoor dat de API niet afhankelijk wordt van de business logic en dus beschermd is tegen veranderingen (dit was meer te verduidelijking voor de andere leden ;)).

Gr,
Erwin

[TheDutch]

TheDutch, owke binding is duidelijk :)
Moet later nog maar een keer uitzoeken hoe je dat doet.

Je kunt in Flex 2 een property bindable maken door er boven of (links) naast te zetten. Je kunt dan dit property binden aan een MXML component op deze manier: <mx:Text text="{propertyNaam}" />. Wanneer "propertyNaam" nu van waarde veranderd zal de "text" property van het Text component automatisch mee veranderen. Dat komt omdat je "propertyNaam" bindable hebt gemaakt. Je kunt ook in Flex 2 ActionScript 3 i.p.v. MXML de class BindingUtils gebruiken. Deze class bevat de method bindProperty() waarmee je een property aan de andere kunt binden wanneer de source property bindable is gemaakt. Voorbeelden (probeer ze uit!):

[b]Flex 2 MXML

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" backgroundColor="0xffffff">

<mx:Script>
<![CDATA[

[Bindable]
public var naam:String = "Peter";

]]>
</mx:Script>

<mx:Text text="{this.naam}" />

<mx:HBox>
<mx:Button label="Peter" click="this.naam='Peter'" />
<mx:Button label="Erwin" click="this.naam='Erwin'" />
<mx:Button label="David" click="this.naam='David'" />
<mx:Button label="Jan" click="this.naam='Jan'" />
</mx:HBox>

</mx:Application>


Flex 2 MXML + AS 3 API

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" backgroundColor="0xffffff" initialize="init()">

<mx:Script>
<![CDATA[
import mx.binding.utils.BindingUtils;

[Bindable]
public var naam:String = "Peter";

private function init():void
{
BindingUtils.bindProperty(this.textField, "text", this, "naam");
}

]]>
</mx:Script>

<mx:Text id="textField" />

<mx:HBox>
<mx:Button label="Peter" click="this.naam='Peter'" />
<mx:Button label="Erwin" click="this.naam='Erwin'" />
<mx:Button label="David" click="this.naam='David'" />
<mx:Button label="Jan" click="this.naam='Jan'" />
</mx:HBox>

</mx:Application>


Flex 2 AS 3 API

package
{
import mx.events.FlexEvent;
import mx.binding.utils.BindingUtils;
import mx.controls.Text;
import mx.containers.Box;
import mx.controls.Button;
import flash.events.MouseEvent;

public class Main extends Box
{
private static const PETER:String = "Peter";
private static const ERWIN:String = "Erwin";
private static const DAVID:String = "David";
private static const JAN:String = "Jan";

private var textField:Text = new Text();

[Bindable]
public var naam:String = Main.PETER;

public function Main()
{
this.direction = "vertical";
this.setStyle("horizontalAlign", "center");

this.addEventListener(FlexEvent.INITIALIZE, init);
}

private function init(event:FlexEvent):void
{
var hBox:Box = new Box();

var button1:Button = new Button();
var button2:Button = new Button();
var button3:Button = new Button();
var button4:Button = new Button();

hBox.direction = "horizontal";

button1.label = Main.PETER;
button2.label = Main.ERWIN;
button3.label = Main.DAVID;
button4.label = Main.JAN;

button1.addEventListener(MouseEvent.CLICK, onButtonClick);
button2.addEventListener(MouseEvent.CLICK, onButtonClick);
button3.addEventListener(MouseEvent.CLICK, onButtonClick);
button4.addEventListener(MouseEvent.CLICK, onButtonClick);

BindingUtils.bindProperty(this.textField, "text", this, "naam");

this.addChild(textField);
this.addChild(hBox);

hBox.addChild(button1);
hBox.addChild(button2);
hBox.addChild(button3);
hBox.addChild(button4);
}

private function onButtonClick(event:MouseEvent):void
{
this.naam = event.currentTarget.label;
}
}
}



Je verhaal van property meegeven als argument begrijp ik grotendeels :)
Al snap ik niet dat je, terwijl er alleen een set is de property kan meegeven.
en... wanneer is dit handig?

Het biedt meer mogelijkheden zonder dat het direct duidelijk hoeft te zijn in welke situatie het handig kan zijn. Het is voor mij aannemelijk dat er van die situaties kunnen bestaan. Een heel simpel voorbeeld is dat je in class1 zit die niet bij de instantie kan van class2. Die class2 heeft een getProperty en setProperty die je benaderbaar wilt hebben vanuit een method in class1 omdat dat property veranderd moet worden na een bepaalde uitkomst of actie. Deze situatie kan je alleen oplossen door de setProperty functie mee te geven als argument aan die method of door een wrapper functie mee te geven als argument die referenties bevat naar getProperty en setProperty (zodat je ze beide beschikbaar hebt binnen één functie argument). Functies zijn namelijk complex types en zodoende worden die als referentie meegegeven in plaats van als copy zoals dat wel gebeurd bij simple types (number, string, etc). Probeer de voorbeelden maar eens in post #25 :).



Bernard & theDutch,
willen jullie de resultaten van jullie onderzoekje anders nog in 1/2 post(s) verzamelen voor me, ik denk dat de bezoeker van dit topic er dan veel meer aan hebt :)

Mijn conclusie is dat de snelheidsverschillen nogal kan verschillen per situatie. Wat wel als paal boven water staat is dat reguliere properties nooit langzamer zijn dan getters en setters en getProperty / setProperty. In geval van bindings kunnen ze wel even snel zijn. Simpel gezegd; reguliere properties gebruik je als snelheid belangrijk is en verder is het vooral zelf goed benchmarken.

[Tha Narie]

Ik weet niet of het altijd goed is om uit te gaan van FlashDevelop. Merendeel van de ActionScript programmeurs (buiten MediaMonks!) zal (nog) gewoon in de Flash IDE werken of in Flex Builder. Daar zit die functionaliteit niet in en dus is dit niet echt een heel sterk argument om aan te geven dat g/s-functies net zo makkelijk aan te vullen zijn met code completion als getters en setters. Dat verschilt per IDE en daarom blijft het een nadeel ven g/s-functies, misschien niet voor jou maar wel voor anderen :).

Daar ben ik het mee eens, het was een aanvulling op jouw "Omdat een prefix voor de property naam code completion vertraagt. Je moet altijd eerst 'set' of 'get' intypen alvorens je met de werkelijke property naam kan gaan beginnen."

Op die manier kan je ook redeneren om altijd 'this.' in classes te gebruiken; omdat deze de autocompletion triggert :)

In dit soort discussies vind ik dat het gebruik in een IDE los moet staan van de keuze die je maakt, het is hooguit een voor- of nadeel waardbij je iets sneller of langzamer werkt! :)

ps.
Programmeurs die nog in de Flash IDE scripten mengen zich volgens mij niet in zulke discussies :P

[matzo]

Ik heb even geprobeerd een duidelijk overzicht te maken(grotendeels gebaseerd op theDutch's post). Iemand die er nog iets aan toe wilt voegen?
Wanneer(en waarom) gebruik ik getters/setters

Wanneer het om het getten en setten van een property gaat met één argument en dat is de waarde.
Omdat je dan één manier hebt om de waarde op te halen en toe te wijzen, in plaats van twee verschillende functies die vaak niet eens onder elkaar in de code completion staan.
Omdat ASDocs wanneer een set of get ontbreekt het herkent als respectievelijk een "read-only" of "write-only" variable en dat snel kan laten zien in de documentatie.
Omdat je zonder verwarring de Set private kan maken en de Get public. Wanneer je dit doet met getProperty en setProperty kan het verwarrend werken aangezien je bij een getProperty ook een setProperty verwacht.
Omdat een Set ook de waarde (intern met Get) weer teruggeeft en dus makkelijk bij formules gebruikt kan worden. Dit kan ook met een setProperty maar dan moet je zelf zorgen voor een return waarde wat niet hoeft met een Set.
Omdat een prefix voor de property naam vaak code completion vertraagt. Je moet in de meeste IDE's eerst "set" of "get" intypen alvorens je met de werkelijke property naam kan gaan beginnen.
Omdat je met een Set heel makkelijk ++ of -- bij een nummer kunt gebruiken. Bij een setProperty moet je dit doen setProperty(getProperty()+1).

Wanneer(en waarom) gebruik ik getProperty()/setProperty()

Wanneer het om het setten van een property gaat met meer dan één argument.
Wanneer de getProperty alleen zijn (nieuwe) waarde mag broadcasten aan zijn binding wanneer ik de opgegeven event type dispatch. Dus handmatige controle over de binding in plaats van een automatische binding.
Wanneer ik de property in een andere scope wil veranderen dan waar de property zich in bevindt. Wanneer je de property neergezet met Get / Set meegeeft aan een functie als argument zal het wijzigen van de waarde alleen van toepassing zijn op de parameter van die functie en niet de werkelijke property. Wanneer je een setProperty functie als functie meegeeft aan een functie dan kan je die later gebruiken om de werkelijke property in die andere scope te setten.


Snelheid:
De snelheid van de verschillende manieren wil wel eens verschillen. Public variables zijn over het algemeent het snelst, maar soms kunnen de andere manieren wel eens even snel zijn. Sneller dan public variables gaat niet voorkomen.
De snelheid kun je verbeteren door in Flex 'bindings' te gebruiken. Zelf testen voor de situatie levert toch nog het meeste op.

En waarom zou ik geen public variables gebruiken?
Het gebruik van get-set/setProperty()-getProperty(), alleen om de variable gelijk te stellen aan een value, zonder verdere acties, kan zinloos lijken. Maar:

Dit kan helpen om in latere versies van de classes de API hetzelfde te houden, terwijl er intern misschien zeer sterke verschuivingen zijn.
Dit kan helpen om de aanmaak van een variable te forceren door een interface. Interfaces mogen immers geen variablen bevatten, maar wel functies als get-setters/getProperty()-setProperty().
get-setters/getProperty()-setProperty() kan je overriden, in tegenstelling tot reguliere properties.

Echt taboe zijn public variables natuurlijk niet, zeker als het om projecten gaat waar snelheid erg gevoelig ligt.
================================================== ===================
@tFW
met

Je zou echter intern ook je getters en setters willen gebruiken, omdat iemand die aan jou class moet werken, niet moet zoeken hoe je private variabele in elkaar zit, maar gewoon de api even moet lezen.
bedoel ik juist dat private variables niet worden meegenomen in de asDoc's.
Stel dat iemand anders jou class moet veranderen. Deze leest natuurlijk even de doc's door, om te weten hoe je code in elkaar zit.

Als je intern dan je private variabele gebruikt, moet de andere in de class zelf opzoeken hoe deze verandert en wat er precies mee bedoeld wordt.

Als je, indien mogelijk, in je class zelf ook de getters/setters gebruikt, weet deze andere al vanuit de api wat de variable voorstelt.

Ook verandert deze man misschien later de naam van de private variable die gecontroleerd wordt door deze getters/setters.

Als je dan in je class de private var hebt gebruikt, moet hij overal in je class de naam van deze var aanpassen.
Als je in je class ook de getter gebruikt om deze var aan te spreken, zoals andere classes zouden doen, moet de andere de naam van de private variable enkel veranderen in de getter/setter.

Maakt dit het duidelijker?

[Tha Narie]

Dit kan helpen om de aanmaak van een variable te forceren door een interface. Interfaces mogen immers geen variablen bevatten, maar wel functies als get-setters/getProperty()-setProperty().
get-setters werken ook niet in een interface als ik het goed heb, alleen echte functies :)

Sowieso vind ik dat het vertragen met autocompletion punt weg kan, want er zijn ook editors die dit helemaal niet hebben (zoals Flash zelf).

[theFlashWizard]

Owke, ik ben het er mee eens dat we niet moeten uitgaan van één programma.
Maar ik zie er niks op tegen om het voordeel bij een specifiek programma erbij te zetten, zolang je het programma er maar duidelijk bij vermeld.
Echter, omdat de search autocompletion het gebruik van een langere syntax maar iets verneld vind ik het niet zo'n interessant punt.

theDutch,
Mooie tutz, daarmee heb ik weer wat gratis inspiratie voor mijn lessen.
Ik zal ook een paar onderdelen bij het OOD gedeelte zetten van me tutorial verzameling.

Bindable verhaal is duidelijk. Ik vind het systeem alleen niet duidelijk. Volgens mij maakt het de source slechter leesbaar / minder duidelijk. Want naast dat de functie (volgens mij) redelijk onbekend is, werkt het alleen met flex (omdat hij in mx package staat) en bestaat zoiets (volgens mij) niet in andere talen.
Maar ik schat in dat jullie het gebruiken voor snelheid, omdat je geen setter / setProperty functies meer nodig hebt, maar de snelheid van een reguliere property zo kunnen gebruiken.
Het lijkt overgens wel op die oude functie om textfields een propery naam mee te geven. Zo'n textfield gaf dan ten alle tijde de inhoud van die property weer.
Misschien een leuke vergelijking als je het nog een keer moet uitleggen :P


Het biedt meer mogelijkheden zonder dat het direct duidelijk hoeft te zijn in welke situatie het handig kan zijn. Het is voor mij aannemelijk dat er van die situaties kunnen bestaan. Een heel simpel voorbeeld is dat je in class1 zit die niet bij de instantie kan van class2. Die class2 heeft een getProperty en setProperty die je benaderbaar wilt hebben vanuit een method in class1 omdat dat property veranderd moet worden na een bepaalde uitkomst of actie. Deze situatie kan je alleen oplossen door de setProperty functie mee te geven als argument aan die method of door een wrapper functie mee te geven als argument die referenties bevat naar getProperty en setProperty (zodat je ze beide beschikbaar hebt binnen één functie argument). Functies zijn namelijk complex types en zodoende worden die als referentie meegegeven in plaats van als copy zoals dat wel gebeurd bij simple types (number, string, etc). Probeer de voorbeelden maar eens in post #25 .
Let eens een beetje op je zin lengte! :D De stof opzich is al lastig genoeg ;)
ZIe er nog niet direct een toepassing van, ik heb ook hierbij dat je script er niet leesbaarder van word. Enigste toepassing die ik kan bedenken is waarbij een method die classes willen bereiken private is. Deze kan de class (van de method) dan alleen aan specifieke classes geven of alleen in bepaalde situaties.
Maar volgens mij kan je dan alsof beter een Proxy pattern gebruiken.

Owke, die conclusie neem ik mee :)

Matzo,
Jeetje, heb ik net een reply geschreven, zie ik dat jij alweer een huge post hebt gemaakt :D

Je hebt me echter wel geïnspireerd tot een nieuwe opbouw van de start topic; in welke situatie wat gebruiken. Want dit werd ook de conclusie uiteindelijk.

Het nut en nadeel van getter, setters, getProperty, setProperty in het algemeen stond bij buiten keif. Maar ik zie dat jullie dit nog kwijt willen dus daar maak ik ook wel wat over in de start topic.

Owke, de verwarring tussen mij en Matzo kwam voort uit de opmerking:
Je zou echter intern ook je getters en setters willen gebruiken
Ik dacht dat hij hiermee het gebruik van private getter setters binnen een class bedoelde.
Hij bedoelde echter gewoon het gebruik van public getters en setters. Want deze worden wel gewoon in asdoc meegenomen.

Tha Narie,
Ik heb het even getest, want ik twijvelde, maar get-setters mogen wel in een interface.

[Tha Narie]

Tha Narie,
Ik heb het even getest, want ik twijvelde, maar get-setters mogen wel in een interface.
**Error** C:\narie\FlashLibrary\com\mediamonks\projects\vrom \stikstof\SliderInterface.as: Line 11: Getter/setter declarations are not permitted in interfaces.


Owke, ik ben het er mee eens dat we niet moeten uitgaan van één programma.
Maar ik zie er niks op tegen om het voordeel bij een specifiek programma erbij te zetten, zolang je het programma er maar duidelijk bij vermeld.

Zo kan je wel veel dingen gaan vermelden, want FlashDevelop heeft ook een plugin om automatisch van je (geselecteerde) private variables, get-setters te maken :)

[theFlashWizard]

Bij mij wel :|
Gebruik jij Flex toevallig? Want misschien dat daar een verschil in zit?
Zou het wel erg vreemd vinden...
Want wat is er op tegen getters setters in een interface te zetten :S

[Tha Narie]

As2/as3 :)

[theFlashWizard]

Er van uitgaande dat dat een vraag was, as3.0 natuurlijk :P

[Tha Narie]

Nee was geen vraag, was de conclusie dat het bij mij (as2) niet werkt en bij jou (as3) wel :)

[TheDutch]

Bindable verhaal is duidelijk. Ik vind het systeem alleen niet duidelijk. Volgens mij maakt het de source slechter leesbaar / minder duidelijk. Want naast dat de functie (volgens mij) redelijk onbekend is, werkt het alleen met flex (omdat hij in mx package staat) en bestaat zoiets (volgens mij) niet in andere talen.

Metadata tags (bindable, style, event, etc) binnen het Flex framework zijn inderdaad in het begin even wennen, maar als je daar doorheen bent gekomen is het alleen maar erg logisch en fijn. Metadata tags waren voorkort onbekend in ActionScript en is natuurlijk zinloos in serverside talen. Logisch dus dat je het niet kent van andere talen. Echter in bijvoorbeeld .NET (C#) gebruiken ze ook bindings op een soort gelijke manier: [System.ComponentModel.Bindable(true)] of [Bindable(true)] wanneer de class ge-import is. Het is blijkbaar een vaker gebruikt concept voor frameworks en zeker niet onbekend voor programmeurs die desktop applicaties ontwikkelen.

Als we gaan kijken naar ActionScript 3 dan kan je inderdaad stellen dat dit een Flex 2 specifiek iets is. Het is onderdeel van dat framework wat je niet zomaar kunt gebruiken in Flash. Wel kan het laatste voorbeeld (zonder de metadata tag [Bindable]) gebruikt worden in Flash wanneer je de BindingUtils class zou porteren naar ActionScript 3 zonder het Flex 2 framework.


Maar ik schat in dat jullie het gebruiken voor snelheid, omdat je geen setter / setProperty functies meer nodig hebt, maar de snelheid van een reguliere property zo kunnen gebruiken.
Het lijkt overgens wel op die oude functie om textfields een propery naam mee te geven. Zo'n textfield gaf dan ten alle tijde de inhoud van die property weer.
Misschien een leuke vergelijking als je het nog een keer moet uitleggen :P

Bindings staan los van het gebruik van een setter / setProperty. Natuurlijk gebruik je bindings voor snelheid en gemak, maar je hebt nog steeds een setter /setProperty nodig wanneer er meer moet gebeuren vóór een property zijn (nieuwe) waarde mag ontvangen :)


ZIe er nog niet direct een toepassing van, ik heb ook hierbij dat je script er niet leesbaarder van word. Enigste toepassing die ik kan bedenken is waarbij een method die classes willen bereiken private is. Deze kan de class (van de method) dan alleen aan specifieke classes geven of alleen in bepaalde situaties.
Maar volgens mij kan je dan alsof beter een Proxy pattern gebruiken.

Het proxy pattern en wat ik net beschreef zijn twee verschillende dingen en niet met elkaar te vergelijken. Het idee is gewoon dat je een functie aan een method kunt meegeven en die gebruiken terwijl je niet een (simpel type) property kunt meegeven en die veranderen. Dat laatste geeft gelijk een toepassing weer waarbij die functies juist een extra doel kunnen bereiken. Dat is het verschil tussen getter/setter en getProperty/setProperty. Dat jij er niet direct een toepassing voor kunt vinden zal je wel vaker tegenkomen bij dingen, maar dat wil niet zeggen dat het daarom maar verwaarloosbaar is hè ;). Naarmate jouw ervaring in het programmeren groeit zul je merken dat je regelmatig zonder direct een toepassing te kunnen bedenken het nut kunt inzien van een bepaalde mogelijkheid die er geboden wordt.


Ik heb het even getest, want ik twijvelde, maar get-setters mogen wel in een interface.
Vanaf AS 3 mag het inderdaad wel en dat brengt weer meer (mooie) mogelijkheden voor interfaces :D.

[BernardV]

Het proxy pattern en wat ik net beschreef zijn twee verschillende dingen en niet met elkaar te vergelijken. Het idee is gewoon dat je een functie aan een method kunt meegeven en die gebruiken terwijl je niet een (simpel type) property kunt meegeven en die veranderen. Dat laatste geeft gelijk een toepassing weer waarbij die functies juist een extra doel kunnen bereiken. Dat is het verschil tussen getter/setter en getProperty/setProperty. Dat jij er niet direct een toepassing voor kunt vinden zal je wel vaker tegenkomen bij dingen, maar dat wil niet zeggen dat het daarom maar verwaarloosbaar is hè ;). Naarmate jouw ervaring in het programmeren groeit zul je merken dat je regelmatig zonder direct een toepassing te kunnen bedenken het nut kunt inzien van een bepaalde mogelijkheid die er geboden wordt.

Heel simpele toepassing waarvan ik weet dat tFW deze ook gebruikt.. onComplete bij Tweener :)

[theFlashWizard]

theDutch,
Owke, goed dat je me over binding corriceert.
Als dit gewoonlijk is voor desktop software zie ik hier ook voor ActionScript toekomst in. Dit gezien het ook steeds meer die kant opgaat.

Bindings staan los van het gebruik van een setter / setProperty. Natuurlijk gebruik je bindings voor snelheid en gemak, maar je hebt nog steeds een setter /setProperty nodig wanneer er meer moet gebeuren vóór een property zijn (nieuwe) waarde mag ontvangen
Dat begreep ik :)

Dat jij er niet direct een toepassing voor kunt vinden zal je wel vaker tegenkomen bij dingen, maar dat wil niet zeggen dat het daarom maar verwaarloosbaar is hè ;)
Dat zou ik zeker niet durfen suggeren ;)
Zo moet ik ook voor final bijv. nog een concrere toepassing verzinnen voor mijn lessen, maar dat geen stof voor dit topic.

Bernard,
Heel simpele toepassing waarvan ik weet dat tFW deze ook gebruikt.. onComplete bij Tweener
Goede ;) Al weet je ook dat ik het met tegenzin doe, want ik vind het een rot manier. Ik had het graag met events gezien.


Ik moet toegeven dat ik redelijk moeite heb met het niveau en het tempo van dit topic.
Maar ik vind het allemaal wel erg leerzaam. Ga zo door!
Ik hoop dat ik in de start topic, een samenvatting en conclusie kan schrijven, die waardig is aan jullie input ;)