Gebruik van _root [Archief]

SaphuA

%Europe/Berlin %672 %2005, 17:08

Het is gewoon zo dat het coden van games zeer verschillend is aan het coden van applicaties. Ik had laatst een duscussie met iemand die alles behalve games maakte, en het gebruik van _root onhandig en bugged vond, wat juist totaal in tegenstelling was met wat ik (en met mij een hoop goede Flash game makers) in gedachte had. Dit soort verschillen kunnen verwarrend zijn voor de beginners.

Dauntless

%Europe/Berlin %684 %2005, 17:26

Dan ben ik geen goede game maker :D

Ik vind dat je nooit _root mag gebruiken. Of het nu gaat om games of applicaties... Gewoon nooit. Ik vind dat als je _root gebruikt, je laat zien dat je a) lui bent , b) je niet weet hoe je applicatie in elkaar zit of c) je niet weet wat het nadeel is :D.

Als je een movie inlaadt in een andere movie veranderd de _root. Spijtig genoeg heeft macromedia 'lockroot' uitgevonden... Daarmee zet je die vast... Maar die lockRoot kwam toch later, wat dus betekend dat het oorspronkelijk niet de bedoeling was...

Als je persé een verwijzing naar de root wil hebben, doe het dan zo:

_global.root = this; (op hoofdtijdlijn). Zo heb je overal de variabele 'root' tot je beschikking en heb je relatieve paden ipv absolute. Ook in een AS 2.00 classe structuur ga je toch geen _root gebruiken?? Je geeft 'this' mee als parameter aan de constructor zodat die weet wat z'n tijdlijn is. Als je in een classe _root gaat gebruiken heb je echt de totale controle verloren...

Roenes

%Europe/Berlin %688 %2005, 17:31

Dat _root verhaal is een andere discussie jongens ;)

Misschien leuk om af te splitsen want dat kan heel interessant worden :)

Dauntless

%Europe/Berlin %692 %2005, 17:37

Dat _root verhaal is een andere discussie jongens ;)

Misschien leuk om af te splitsen want dat kan heel interessant worden :)
Ja, dacht ik ook :). Even afsplitsen naar ASSC

Mitch

%Europe/Berlin %708 %2005, 18:00

Ik vind dat je nooit _root mag gebruiken. Of het nu gaat om games of applicaties... Gewoon nooit. Ik vind dat als je _root gebruikt, je laat zien dat je a) lui bent , b) je niet weet hoe je applicatie in elkaar zit of c) je niet weet wat het nadeel is :D.

Ik gebruik bijna altijd root :p lekker makkelijk voor kleine dingetjes. Maar voor andere dingen probeer ik het zelfs te vermijden ja :)

Maar ontopic, een game forum is toch veeelste algemeen :)

Dat zie je aan hierboven reactie over _root :) Maar met AS is het toch dat je verschillende dingen voor verschillende doeleinden kan gebruiken. Of zit ik nu weer slap te praten :)

Jorim

%Europe/Berlin %717 %2005, 18:12

Op verzoek gesplitst ;)

Ben

%Europe/Berlin %831 %2005, 20:56

Ey Saphua :) Ben ik 'die ander' ? (goed discussie punt dit trouwens. Ben ook benieuwd wat anderen er van vinden. Wordt graag gewezen op mijn evt. ongelijk)

Heb mijn standpunt hierover in ieder geval duidelijk proberen te maken in deze (http://www.flashfocus.nl/forum/showthread.php?t=2474) thread. Dus laat maar horen die tegenargumenten :) Even voor de duidelijkheid, games en/of applicaties zie ik in dit opzicht 0,0 verschil tussen. Het maken van games neemt niets weg van het principe dat _root 'gevaarlijk' kan zijn. En 'for the record'.... de games ervaring in flash is hier gerust aanwezig hoor :) Anders had ik er ook geean mening over kunnen hebben.

Dauntless

%Europe/Berlin %933 %2005, 23:23

Ik ben dus (zoals ik al zei) ook 100% tegen root! :)

Oa ook vanwege wat ben zei... Stel je hebt je game / app af... Nu plots moet die in een nieuwe mc komen... Ga jij dan al je _root's opsporen en aanpassen aan de nieuwe situatie?

En SaphuA's argument van 'na een tijdje vergeet je waar hij naar linkt'. In principe (ben het zelf nog aan het leren :p) zou je altijd je code goed moeten becommentariëren...

//verwijder de window
this._parent.removeMovieClip();//(bv in een app waar je dus windows met een sluitknop hebt)

The_One

%Europe/Berlin %950 %2005, 23:49

Ik gebruik alleen _root bij het testen [en als ik lui ben].
Het is gewoon beter om relative paden te gebruiken [dus geen _root], want je gaat problemen krijgen als je met loadMovie[Num] gaat werken bijvoorbeeld; je moet dan weer je hele FLA aanpassen!

Dauntless

%Europe/Berlin %953 %2005, 23:53

Ik gebruik alleen _root bij het testen [en als ik lui ben].
Bedoel je dan: "crap, het werkt niet, dan maar ff proberen met _root" ?

The_One

%Europe/Berlin %955 %2005, 23:56

jep, dan kan ik namelijk wel zien of alles werkt :)
Als alles werkt, dan probeer ik er een relatief pad van te maken, want dat moet dan mogelijk zijn.
Als het [ook] niet werkt met _root, dan weet je dat je een foutje ergens heb zitten :)

peres

%Europe/Berlin %968 %2005, 00:14

met de target-optie in het AS scherm kan het toch niet fout gaan? :)

Dauntless

%Europe/Berlin %969 %2005, 00:16

met de target-optie in het AS scherm kan het toch niet fout gaan? :)
Bestaat dat dan? :o :D

peres

%Europe/Berlin %972 %2005, 00:20

http://members.chello.nl/r.stultiens/target.JPG

Dauntless

%Europe/Berlin %974 %2005, 00:23

img
Hehe, 'k wist wel dat hij bestond hoor ;) 'k heb hem gewoon nog noooit gebruikt :). In principe weet je toch wel altijd waar je je bevind in de structuur... Anders doe je ff trace(this); et voila :)

peres

%Europe/Berlin %976 %2005, 00:26

Hehe, 'k wist wel dat hij bestond hoor ;) 'k heb hem gewoon nog noooit gebruikt :). In principe weet je toch wel altijd waar je je bevind in de structuur... Anders doe je ff trace(this); et voila :)

ja je hebt gelijk, maar de target-optie is wel handig omdat je geen typfouten kan maken, en hij meteen ziet of een MC geen instance name heeft :)

The_One

%Europe/Berlin %986 %2005, 00:39

Maar dynamisch aangemaakte MCs komen [helaas] niet in dat venstertje. Ik gebuik dat venstertje soms ook ja :)

Folkert

%Europe/Berlin %595 %2005, 15:17

Er is op de time line niet zoveel mis met _root hoor ;) Dat je het beter niet kan gebruiken en altijd relative paden zou moeten gebruiken vind ik dan ook onzin.
Ga je as2 classes bakken, dan word het een ander verhaal. dan geen _root please.

Dauntless

%Europe/Berlin %602 %2005, 15:28

Zogouw je hem dan inlaadt in een andere movie is de _root veranderd en mag je heel je app gaan herschrijven?

Of als je hem gewoon plots helemaal in een nieuwe mc wilt zetten... Dan zijn ook al je _root paden naar de maan ;)

(Grrr, marcomedia had echt die lockroot er niet mogen insteken :p)

Roenes

%Europe/Berlin %696 %2005, 17:42

Het gebruik van _root kan best, mits je heel goed nadenkt over je app voordat je begint met programmeren. Zo zijn er (in mijn ogen) een aantal regels wanneer je zeker geen _root moet gebruiken:

- Gebruik van AS2 classes
- Mogelijkheid van het (toekomstig) inladen van je swf
- Mogelijkheid van het (toekomstig) verplaatsen van je code naar mc of naar een andere fla
- Als je _root niet gebruikt buiten debug mogelijkheden

_root kan heel makkelijk zijn met debuggen om even te testen of je code werkt zodat je weet dat het aan je path ligt. Toch gebruik ik _root zelf nooit. Ik ga er altijd van uit dat de mogelijkheid bestaat dat ik laten met swfje kan gaan inladen in een ander. Ik heb dan geen zin om je kant en klare app aan te passen. En neej, ook niet om alleen een lockroot regel erin te zetten. Me app werkt en daar blijf ik van af als ik daar iets mee wil doen in een andere app. Het origineel ga je dan niet aanpassen.

Een ander voordeel van relatieve paden is, dat deze altijd gelijk blijven mits je in de hierarchie van mc's niets aanpast. Dus als je het hele handeltje verplaatst naar een mc, dan veranderd alleen het hoogste niveau, maar aangezien je die nooit direct aanspreekt hoef je je code niet te veranderen :)

Ik weet niet of _root ook een "bad practise" is, maar ik weet wel dat de meeste gevorderden scripters geen _root gebruiken. Dat kan geen toeval zijn ;)

Maar als je goed weet waar je mee bezig bent en je weet zeker dat je swf altijd op zichzelf staand zal blijven, dan is er op zich geen bezwaar voor het gebruik van _root. :)

Tommyfied

%Europe/Berlin %438 %2005, 11:31

_root kan heel makkelijk zijn met debuggen om even te testen of je code werkt zodat je weet dat het aan je path ligt.

Dat roepen nu al een paar mensen ... maar daar kan ik bij mijn verstand echt niet bij. Ik vind het gebruik van this (i.c.m. _parent) zo duidelijk als iets. Ik snap ook niet goed wanneer je dan met _root wilt testen of je pad goed is ... (_root is namelijk zelf ook "relatief" ... als je echt absolute paden gebruiken wilt (voor test redenen of wat dan ook) gebruik dan _level0 (of _level1 of ... _leveln).

Maargoed dat kan misschien ook aan mij liggen? :p

Tha Narie

%Europe/Berlin %496 %2005, 12:55

Inderdaad, debuggen doe je met trace(this);
Niks _root!

Tommyfied

%Europe/Berlin %627 %2005, 16:04

Woohoo! :P Helemaal mee eens :P

latino

%Europe/Berlin %631 %2005, 16:09

als het zo slecht is had macromedia _root niet uitgevonden/gecreeerd denk ik :)

Tommyfied

%Europe/Berlin %638 %2005, 16:19

Hahaha wat een naïviteit! :P Nee even serieus:

_root is niet voor niks (niet goed) toepasbaar in Actionscript 2.0. _root stamt nog net als veel andere syntax uit het Actionscript 1.0 tijdperk (en zelfs daar kun je eigenlijk beter this gebruiken). Ben ook benieuwd hoelang het duurt voor het deprecated wordt en je alleen echt relatief (this) of echt absoluut (_level0 etc) kunt verwijzen naar paden.

Roenes

%Europe/Berlin %641 %2005, 16:23

Dat roepen nu al een paar mensen ... maar daar kan ik bij mijn verstand echt niet bij. Ik vind het gebruik van this (i.c.m. _parent) zo duidelijk als iets. Ik snap ook niet goed wanneer je dan met _root wilt testen of je pad goed is ... Daar bedoelde ik mee dat als je een diep geneste mc een andere diep geneste mc wil aansturen, dat een verwijzing startend bij _root makkelijker is om te maken dan via this._parent._parent._parent.enz...

Ik zeg ook niet dat ik dat doe, ik zeg alleen maar dat ik me kan voorstellen dat mensen dat doen ;) Zelf ga ik voor this en _parent all the way! :)

Tommyfied

%Europe/Berlin %646 %2005, 16:30

Als je vaak _parent._parent._parent enz. gebruikt moet je eens nadenken over je mc structuur :P

Roenes

%Europe/Berlin %654 %2005, 16:43

Klopt, maar er bestaat altijd een kans dat je die geneste mc's krijgt. Denk dan vooral aan grote spellen en grote applicaties :)

Tommyfied

%Europe/Berlin %656 %2005, 16:44

En als het goed is heb je bij grote spellen / applicaties ervoor gezorgd dat alle onderdelen onafhankelijk zijn van elkaar en netjes met elkaar communiceren via listeners ed. :P Oftwel je hebt modulair geprogrammeerd. :P Maar dit gaat een beetje de andere kant op.

Roenes

%Europe/Berlin %657 %2005, 16:46

[m]

%Europe/Berlin %877 %2005, 22:02

Als je vaak _parent._parent._parent enz. gebruikt moet je eens nadenken over je mc structuur :P

Je bent zowiezo stom bezig als je gaat bemoeien met de paths. Gebruik voor alles een variabele, werkt een stuk beter en is ook nog eens overzichtelijker. :)

Dauntless

%Europe/Berlin %887 %2005, 22:18

']Je bent zowiezo stom bezig als je gaat bemoeien met de paths. Gebruik voor alles een variabele, werkt een stuk beter en is ook nog eens overzichtelijker. :)
var targetMc:MovieClip = this._parent._parent._parent;
targetMc.stop();

//zo ?:D

Dan moet je weer variabelen global gaan maken... Of wat bedoel je?

Roenes

%Europe/Berlin %891 %2005, 22:24

ik denk dat [m] bedoelt om per timeline een var te maken. Net zoals (sommige) bij xml in de onLoad doen:

var xml = this;
for(var i = 0; i < xml.childNodes.length; ++i)
{
var node = xml.childNodes[i];
for(var j = 0; j < node.length; ++i)
{
var subnodes = node.childNodes;
//Overige code
}
}
Code klopt misschien niet helemaal lekker, maar het gaat om het idee ;)

[m]

%Europe/Berlin %028 %2005, 01:40

Denk ook aan je structuur in je site. Handig dat je een map_holder in een boek_holder in een kast_holder hebt zitten, want dan kan je de hele tijd:

kast_holder.boek_holder.map_holder._x = 5;
kast_holder.boek_holder.map_holder._y = -154;
kast_holder.boek_holder.map_holder._width = 66;
kast_holder.boek_holder.map_holder._alpha = 15;

Gaan schrijven. Makkelijker is:

map_holder = kast_holder.boek_holder.map_holder;
map_holder._x = 5;
map_holder._y = -154;
map_holder._width = 66;
map_holder._alpha = 15;

Want het is overzichtelijker en simpeler. Als je het he-le-maal tof wilt hebben doe je:

_global.map_holder = kast_holder.boek_holder.map_holder;
_global.map_holder._x = 5;
_global.map_holder._y = -154;
_global.map_holder._width = 66;
_global.map_holder._alpha = 15;

Maar dat is een beetje overkill en als je alles een beetje uitdenkt (lees: alle code op de eerste frame van de _root of met classes) hoef je _global nooit te gebruiken. :)

Dauntless

%Europe/Berlin %276 %2005, 07:37

Zelf geloof ik ook niet echt in die _global... Maar da's natuurlijk een andere discussie ... Het enige wat ik er handig van vind is een 'global debugfunctie' (for(i in object) trace(object[i]); ) omdat ik eens problemen had dat hij mij het niet direct liet doen...

Doc

%Europe/Berlin %484 %2005, 12:37

maar als ik nou in een MC zit, die in een MC zit, die in een MC zit enz.....
hoe verwijs ik dan naar de root??

*edit* sry, ik zal vooraan eerst alle pagina's lezen voor ik post [:o)]

Roenes

%Europe/Berlin %490 %2005, 12:46

this._parent._parent._parent.enz dus het aantal parent is afhankelijk van hoe diep je mc genest is :)

Ben

%Europe/Berlin %550 %2005, 14:12

']Denk ook aan je structuur in je site. Handig dat je een map_holder in een boek_holder in een kast_holder hebt zitten, want dan kan je de hele tijd:

kast_holder.boek_holder.map_holder._x = 5;
kast_holder.boek_holder.map_holder._y = -154;
kast_holder.boek_holder.map_holder._width = 66;
kast_holder.boek_holder.map_holder._alpha = 15;

Gaan schrijven. Makkelijker is:

map_holder = kast_holder.boek_holder.map_holder;
map_holder._x = 5;
map_holder._y = -154;
map_holder._width = 66;
map_holder._alpha = 15;

Want het is overzichtelijker en simpeler. Als je het he-le-maal tof wilt hebben doe je:

_global.map_holder = kast_holder.boek_holder.map_holder;
_global.map_holder._x = 5;
_global.map_holder._y = -154;
_global.map_holder._width = 66;
_global.map_holder._alpha = 15;

Maar dat is een beetje overkill en als je alles een beetje uitdenkt (lees: alle code op de eerste frame van de _root of met classes) hoef je _global nooit te gebruiken. :)

Okay, first things first ;) Voor alles is een reden. Dat je zelf niet iets gebruikt kan ook andere oorzaken hebben :D

Then, gebruik van _global is in my humble opinion misschien nog wel gevaarlijker dan _root. Voor schijnbaar unieke namen als "map_holder" kan ik me erbij voorstellen dat je er maar 1 van hebt, maar wat als je een mc "Button" hebt? Welke dan? Of om het dilemma compleet te hebben en de visuele cirkel rond te maken, wat doe je als je mc in een andere wordt ingeladen die toevallig ook een "Map_Holder" heeft? Misschien toch niet zo gek dat bemoeien met paden?

[m]

%Europe/Berlin %623 %2005, 15:57

Okay, first things first ;) Voor alles is een reden. Dat je zelf niet iets gebruikt kan ook andere oorzaken hebben :D
Ik zeg niet dat je iets niet mag gebruiken, ik zeg alleen dat je weet waar je bezig mee bent. Ikzelf gebruik vaak de _root als ik variabelen voor iedereen makkelijk aanroepbaar wil maken, maar ik laad ook heel weinig swf's in. Als ik swf's in ga laden, dan is het natuurlijk een heel anderverhaal, want dan klopt er geen hout meer van. ;)

Then, gebruik van _global is in my humble opinion misschien nog wel gevaarlijker dan _root. Voor schijnbaar unieke namen als "map_holder" kan ik me erbij voorstellen dat je er maar 1 van hebt, maar wat als je een mc "Button" hebt? Welke dan? Of om het dilemma compleet te hebben en de visuele cirkel rond te maken, wat doe je als je mc in een andere wordt ingeladen die toevallig ook een "Map_Holder" heeft? Misschien toch niet zo gek dat bemoeien met paden?
Dat zijn wel heel erg veel "als". Er zijn heel veel situaties te bedenken die een algemene aanpak kunnen gebruiken, maar net zo veel situaties die een specialistische aanpak nodig hebben. Als je niet weet waar je een variabele map_holder voor hebt gebruikt en in welke context, ligt het niet aan de code die je gebruikt maar de gebruiker zelf. ;) Eerst denken, dan doen.

Nov1

%Europe/Berlin %636 %2005, 16:16

Het is onzin om absoluut nooit _root te gebruiken. En waarom vindt zou je het vervelend vinden dat MM lockroot heeft gemaakt, is toch gewoon handig. Hoef je niet je hele projecten om te gooien.

Dauntless

%Europe/Berlin %666 %2005, 17:00

Ja, eindelijk, ik heb het pdfje gevonden waar ik al zooo lang naar zoek!!

"Actionscript Coding Standards!" (http://download.macromedia.com/pub/devnet/downloads/actionscript_standards.pdf)
Waar dus ook in staat:

Scope variables using relative addressing
All variables should be scoped. The only variables that are not scoped are function parameters and local variables. Variables should be scoped relative to their current path if possible. Scoping a variable from the _root is not recommended because this limits the portability of the code. Use the keyword _parent or this instead, for example:
this.myVar.blah = 100; // scope variables using relative addresses like this
_root.myMovieClip.myVar.blah = 100; // do not scope variables using absolute addressing like this
If absolute addressing to the main timeline must be used, create a variable to reference the main timeline instead of using _root. This allows for easy modification of a single parameter if the timeline structure changes. To create a convenient reference to the main timeline of a movie, add this line of code to the main timeline:
_global.myAppMain = this; // (substitute the name of your application for "myApp")
After inserting this line of code into the application, use _global.myAppMain.someFunction to refer to functions on the main timeline. This allows the application structure to change without breaking the scope of function calls and variables in the movie.

[m]

%Europe/Berlin %699 %2005, 17:47

Ja, eindelijk, ik heb het pdfje gevonden waar ik al zooo lang naar zoek!!

"Actionscript Coding Standards!" (http://download.macromedia.com/pub/devnet/downloads/actionscript_standards.pdf)
Waar dus ook in staat:

GEWELDIGE NIEUWE INFORMATIE!!!

Lees iedereen zijn posts nog eens door, wij zeggen allemaal dat het de "portability", dwz. het aanpassingsvermogen, van de coden verminderd.

PS dat pdf is alleen tips, geen harde regels.

Roenes

%Europe/Berlin %702 %2005, 17:51

En waarom vindt zou je het vervelend vinden dat MM lockroot heeft gemaakt, is toch gewoon handig. Hoef je niet je hele projecten om te gooien.lockroot is zeker handig, maar doordat ze dit soort dingen erin zetten nemen mensen niet de moeite om te switchen naar relatieve paden. "Waarom al je paden veranderen als 1 regel toevoegen genoeg is?" Dat denken zij dan.

Maar als je dat denkt, moet je zelf inzien dat je verkeerd bezig bent. Je moet een ingreep maken omdat anders de boel niet naar behoren werkt. Dat betekend dus dat het hele zaakje in eerste instantie niet lekker in elkaar zit.

Met lockroot zet je _root kunstmatig vast aan een timeline. Deze timeline is niet meer de _root als je em gaat inladen. Dan is het gebruik van _root dus zoek, want die verwijst dan dus niet meer naar de bovenste tak van de boom...

Om maar niet te spreken van movies inladen in movies die zelf ook weer ingeladen worden :D

]PS dat pdf is alleen tips, geen harde regels.Uiteraard. Hiervoor zijn geen harde regels. Maar dat is met alle best practises. Het zijn geen vaststaande regels, maar ze worden niet voor niets best practise genoemd he ;)

Dauntless

%Europe/Berlin %706 %2005, 17:56

']GEWELDIGE NIEUWE INFORMATIE!!!
Ik reageerde op Nov1, die zei dat het niet waar was om absoluut nooit _root te gebruiken. Echter wordt het wel door macromedia 'aangeraden' als tip, dus er zal ergens wel een beetje waarheid in zitten...

PS dat pdf is alleen tips, geen harde regels.
Wel, d'uh, niemand kan je verplichten om een bepaald gebruik te hanteren... Maar 'k bedoel... Als nu iedereen zegt dat iets op een bepaalde manier heel goed is, dan is het toch misschien logisch dat je dat ook gaat doen... Maar dat moet nog altijd niet natuurlijk, je doet maar wat je wil...

[m]

%Europe/Berlin %741 %2005, 18:48

Ik reageerde op Nov1, die zei dat het niet waar was om absoluut nooit _root te gebruiken. Echter wordt het wel door macromedia 'aangeraden' als tip, dus er zal ergens wel een beetje waarheid in zitten...

Wel, d'uh, niemand kan je verplichten om een bepaald gebruik te hanteren... Maar 'k bedoel... Als nu iedereen zegt dat iets op een bepaalde manier heel goed is, dan is het toch misschien logisch dat je dat ook gaat doen... Maar dat moet nog altijd niet natuurlijk, je doet maar wat je wil...

Lees deze post eens door en zie of er nieuwe informatie in staat, of een mening dat alles van een nieuwe kant belicht.

Tha Narie

%Europe/Berlin %789 %2005, 19:57

Heeft iemand dit al eens geprobeerd, bij een SWFje waar je lockroot hebt staan:

_root._parent
Wie weet ;) Hoe verwarrend :P

Ben

%Europe/Berlin %301 %2005, 08:13

Volgens mij is het een welles nietes gebeuren aan het worden :) Als ik zo vrij mag zijn om even te resumeren, heeft (bijna) iedereen wel op de een of andere manier aangegeven dat het niet 'je van het' is om _root te gebruiken. De argumenten om wel _root te gebruiken zijn naar mijn idee enkel uit het oogpunt van gemak. Ik heb in ieder geval nog geen punten gehoord "dan en dan kun je niet zonder_root". Dat geeft ook niet en is ook niet bedoeld als uitdaging om die punten te verzinnen. Iedereen uiteraard zijn eigen manieren met zijn eigen beweegredenen. Ik heb er in ieder geval weer wat over opgestoken.

Mediamonkey

%Europe/Berlin %414 %2005, 10:56

Laten we het dan meteen hebben over OO programmeren.
Daarin is de regel dat elk object hooguit met zijn directe buurman kan communiceren, en niet verder. Nu is Flash wel een heel stuk flexibeler waardoor je soms makkelijker een stuk code uitschrijft als een rijtje _parent's, maar het zou volgens OOP niet mogen.

Zorg, als je classes gebruikt, er gewoon voor dat wanneer een nieuw object wordt aangemaakt, dat je direct in de argumenten de parent meegeeft als referentiepunt. Of je laat 'm registreren op de een of andere manier, of je gebruikt een mix-in, of je stuurt 'm alleen aan vanuit z'n parent. Maar om dus uiteindelijk iets op de _root aan te kunnen roepen zou het volgens deze methode moeten via myParent.getRoot(); Waarbij dat object ook weer aan ZIJN parent getRoot() aanroept en zo de hele structuur af tot de root is bereikt en deze wordt teruggegeven.

Lekker duidelijk of maak ik 't er alleen moeilijker op? :S

Tommyfied

%Europe/Berlin %597 %2005, 15:21

Nee joh dit is tenminste klare en duidelijke taal :P Vind ik dan ... en eigenlijk ook een oplossing voor deze hele discussie. :)

Allen gaat OOP'en :P

Nightbowl v2.

%Europe/Berlin %314 %2005, 08:33

Tha Narie

%Europe/Berlin %388 %2005, 10:19

Ben ook benieuwd hoelang het duurt voor het deprecated wordt en je alleen echt relatief (this) of echt absoluut (_level0 etc) kunt verwijzen naar paden.
Als je je SWFjes met loadMovieNum in een level laadt, is _root beter dan _levelx, omdat je vanuit je SWF niet weet in welk level hij wordt geladen, en je daarom _root kunt gebruiken om naar de root van dat level te gaan. _levelx gebruiken is dan helemaal FOUT!

Roenes

%Europe/Berlin %481 %2005, 12:33

Volgens mij is de beste oplossing als je toch een soort van root wil gebruiken, om je eigen root te maken dmv een var (is eerder gemeld)
var root = this;Volgens mij heeft dit geen nadelen ten behoeve van het mogelijk inladen ed omdat je relatief verwijst naar een "eigen" root. Je gebruikt dan toch een root maar je hebt wel relatieve paden :)

Tha Narie

%Europe/Berlin %500 %2005, 13:00

Niet op die manier dan, want dan kan je vanuit geneste MC's die variable niet direct aanspreken.
Je zou hem dan globaal moeten maken.
Wat ook conflicten op kan leveren als je 1 SWF 2x inlaadt.

Roenes

%Europe/Berlin %556 %2005, 14:21

Damn! Heb je helemaal gelijk in. :)

Dauntless

%Europe/Berlin %640 %2005, 16:21

Allen gaat OOP'en :P
Vind ik een goede oplossing :D

En voor de rest alleen code op hoofdtijdlijn zetten... Dan heb je niets problemen :).
(Ok, dat van hierboven hangt natuurlijk wel wat af van de structuur, maar als je je structuur goed kiest zou dat toch moeten lukken...)

Fatty Owl

%Europe/Berlin %862 %2005, 21:42

en ik altijd denken dat het in actionscript ook ging om zo kort mogelijke codes te schrijven :O .

stomme boek, hij zegt selecteer relative en nu doe ik het automatisch:D

Roenes

%Europe/Berlin %523 %2005, 13:33

en ik altijd denken dat het in actionscript ook ging om zo kort mogelijke codes te schrijven :O .ook ook, maar dat staat weer in verband met leesbare code :p

Maar dat is weer een andere discussie dus daar ga ik in deze topic niet op in ;)

Ben

%Europe/Berlin %589 %2005, 15:08

[m]

%Europe/Berlin %943 %2005, 23:38

Ehhh, regel dat elk object hooguit met zijn buurman kan praten ??? Que, waar heb je die regel vandaan? :) Is volgens mij nl. niet een 'regel'. Dat iemand zich dat aangeleerd heeft prima, maar regel voor oop? Correct me if i'm wrong.

Het is een onderdeel van de OOP methode (kan je aanzetten als je wilt) maar je hebt gelijk, het is geen regel dat ALTIJD geld.

Tommyfied

%Europe/Berlin %995 %2005, 00:53

Vind ik een goede oplossing :D

En voor de rest alleen code op hoofdtijdlijn zetten... Dan heb je niets problemen :).
(Ok, dat van hierboven hangt natuurlijk wel wat af van de structuur, maar als je je structuur goed kiest zou dat toch moeten lukken...)

Alle code in een los as bestand bedoel je! Aral Balkan's presentatie niet gezien op het Flashtival vorig jaar? :P

(wanneer issie dit jaar trouwens ??? :D)

Dauntless

%Europe/Berlin %265 %2005, 07:21

Alle code in een los as bestand bedoel je! Aral Balkan's presentatie niet gezien op het Flashtival vorig jaar? :P

(wanneer issie dit jaar trouwens ??? :D)Nee, niet gezien... 'k Ben nog nooooit naar een of andere flash presentatie gegaan. Maar als m'n code in de .fla te lang wordt ga ik ook een externe .as nemen omdat SE|PY nu eenmaal veel aangenamer werkt :D.

Maar als je die dan include in je hoofdtijdlijn staat eigenlijk toch al je code op de 'root' ?

Tha Narie

%Europe/Berlin %411 %2005, 10:52

Ja :P

Maar gewoon met classes werken, 10x beter!

Ben

%Europe/Berlin %426 %2005, 11:14

Eenmaal gewend aan classes wil je nooit meer anders..... ga je zelfs de meest lullige dingen in classes stoppen :D Maar het is gewoon zo veel fijner werken.

Tommyfied

%Europe/Berlin %570 %2005, 14:41

Ik bedoel natuuuurlijk classes he dan ... hang de code aan een mc ... als je een nieuwe mc maakt kun je ook een class eraan hangen ;)

Om nog maar te zwijgen over het gebruiken van forms / screens :)

oh,when?

%Europe/Berlin %000 %2005, 01:00

Cowerd

%Europe/Berlin %873 %2005, 21:57

whoaa na het lezen van dit topic vind ik _root niet cool meer:P
Weer een stap in de richting van AS-master:P

Al zal ik dat wellicht nooit worden:D

SaphuA

%Europe/Berlin %903 %2005, 22:40

Nou, ik ben nog steeds niet overtuigd om _root niet te gebruiken...
Zolang je alles van te voren goed pland is er geen reden om je ergens zorgen over te maken :)

_root to the people!

Dauntless

%Europe/Berlin %924 %2005, 23:11

Wel, ik heb er niets tegen van mensen die het gebruiken... Maar zoals je zegt moete ze wel beseffen dat ze het gebruiken (ok, vreemde zin :D). Maar er zijn héél veel mensen die gewoon denken: ok, ik smijt al m'n vars op de hoofdtijdlijn, ik benader ze met _root.var en alles komt in orde... Maar dat vind ik echt een LELIJKE manier van scripten ....

TheZwier

%Europe/Berlin %925 %2005, 23:12

Ik gebruik ook altijd _root :). Alleen al omdat ik nog nooit gebruik gemaakt heb van loadmovie :)
Ik ken de nadelen, maar voor mij gaat _root typen nog altijd sneller dan te gaan bedenken hoe diep ik genesteld zit en kijken hoeveel _parents ik moet gebruiken :D

Dauntless

%Europe/Berlin %928 %2005, 23:17

Bij mij staat eigelijk altijd 99% van m'n code op de '_root' ;) Dus 'this' is korter dan _root :D

Cowerd

%Europe/Berlin %976 %2005, 00:25

bij mij eigenlijk ook..

Ben

%Europe/Berlin %961 %2005, 23:04

']Het is een onderdeel van de OOP methode (kan je aanzetten als je wilt) maar je hebt gelijk, het is geen regel dat ALTIJD geld.

Werd door een notifier weer even dit subject in getrokken :) Dus heeeele late reactie, maar ach. Met alle respect bedoel ik dit, maar waar haal je dit vandaan? "de OOP methode" ?? "kun je aanzetten" ??

Volgens mij verwar je het concept OOP met iets wat het dus niet is :) Of ik ben gek natuurlijk dat kan ook. OOP en praten met buren heeft naar mijn idee niets met elkaar te maken. Roep het maar, omdat het voor mensen die dit topic nalezen verwarrend kan zijn.

Ben

%Europe/Berlin %964 %2005, 23:08

De topicstarter heeft het over het gebruik van _root in games, en bij sommige genre games is performance een belangrijk gegeven. Daarom is het gebruik van _root niet eens zo'n slecht idee. Dit omdat bij het gebruik van classes en this referenties de compiler deze vertaald aan de hand van zogenaamde scoping rules (de zogenaamde inheritance chain mbv __proto__ ). Actionscript 2 wordt immers nog steeds vertaald naar Actionscript 1.

De bytecode die hiermee gegenereerd wordt, maakt veel gebruik van zogenaamde getMember calls (zoek dat maar eens op in de SWF specificatie :) ). In het kort gezegd kun je zeggen dat, hoe minder getMember calls, hoe sneller de actionscript wordt uitgevoerd. Door het gebruik van _root, wordt er andere bytecode gegenereerd met in de meeste gevallen, minder getMember calls. Het is zelfs toegestaan om de ouderwetse Flash 4 "slash" syntax te gebruiken (hoewel ik het niemand kan aanraden, alleen om in de allerlaatste fase meer performance te krijgen.). Ik ken voorbeelden van Flash 5/6/7 bestanden die door zo'n optimalisatie een performance winst boeken van wel 30%. Significant detail is dat de Flash 8 compiler en player geoptimaliseerd is, zodat eerdergenoemde hack eigenlijk weer nutteloos is.

Lesje bytecode hacking zo midden in de nacht 8-)

Ola, interessant gegeven dit. Ik heb er nog nooit van gehoord, maar als het zo is is het inderdaad een mogelijk argument om wel voor _root te kiezen. Ik vind het wel moeilijk aan te nemen van je die 30% (eigenwijze rotz*k ben ik ook he) dus als je ergens een benchmark hebt ben ik zeer geinterresseerd. Ik denk (zeker met fp8) dat je de boot in de toekomst wel gaat missen qua optimalisaties als je blijft hangen in oude 'oplossingen' moet ik wel zeggen. (probeer de fp8.5 eens anders met de zaken die je noemt? Ben erg benieuwd wat die er van maakt.)

Ben

%Europe/Berlin %966 %2005, 23:11

Nou, ik ben nog steeds niet overtuigd om _root niet te gebruiken...
Zolang je alles van te voren goed pland is er geen reden om je ergens zorgen over te maken :)

_root to the people!

Geeft ook helemaal noppes :) Laten we vooral genieten van de vrijheid die flash IDE je geeft mbt hoe iemand zijn code wil managen. Dus vooral vrijheid blijheid en in de eerste plaats altijd doen wat je zelf het snels en prettigst vind werken. Maar voor de personen die zich afvragen "wat is best practice" blijf ik de discussie wel van belang vinden. Hoewel we ondertussen allemaal wel de voors en tegens hebben duidelijk gemaakt :) Dus welles nietes enzo ;)

Dauntless

%Europe/Berlin %982 %2005, 23:34

Ben, je kan ok gewoon je vorige post wijzigen hé ;).

SaphuA

%Europe/Berlin %021 %2005, 00:31

Ik vraag me af of deze resultaten enigsinds accuraat en betrouwbaar zijn, maar zal ze toch even posten:

Local:
_root: 156
this: 145
niets: 195

Vanuit mc:
_root: 515
_parent: 527

Local:
_root: 138
this: 154
niets: 195

Vanuit mc:
_root: 518
_parent: 531

Local:
_root: 144
this: 146
niets: 195

Vanuit mc:
_root: 520
_parent: 519

Hoe ik dit getest heb:
- Code op de root (frame 1):
var test = "Dit is een waarde :)";
//--
var timer = 0;
this.onEnterFrame = function() {
if (++timer%20 == 1) {
trace("Local:");
var t1 = getTimer();
for (var a = 0; a<100000; a++) {
var a1 = _root.test;
}
trace(" _root: "+(getTimer()-t1));
//--
var t2 = getTimer();
for (var b = 0; b<100000; b++) {
var a2 = this.test;
}
trace(" this: "+(getTimer()-t2));
//--
var t3 = getTimer();
for (var c = 0; c<100000; c++) {
var a3 = test;
}
trace(" niets: "+(getTimer()-t3));
trace("");
}
};
- Code op een MC:
onClipEvent (load) {
var timer = 0;
}
onClipEvent (enterFrame) {
if (++timer%20 == 10) {
trace("Vanuit mc:");
var t1 = getTimer();
for (var a = 0; a<100000; a++) {
var a1 = _root.test;
}
trace(" _root: "+(getTimer()-t1));
//--
this.t2 = getTimer();
for (var b = 0; b<100000; b++) {
var a2 = _parent.test;
}
trace(" _parent: "+(getTimer()-this.t2));
trace("");
}
}
Wat er uit de resultaten te zien is?
- Vanuit een MC roepen naar naar een variable op een ander level vele male langzamer dan waneer je dit op het level zelf doet.
- Het is altijd sneller aan te geven waar je de variable vandaag haalt (this. is sneller dan niets aangeven)
- Het gebruik van this. ipv _root. is iets sneller
- Het gebruik van _root. ipv _parent. is iets sneller

Hoop dat iemand er wat aan heeft :)
Ik vind de resultaten niet echt schikwekkend of zo...

Ben

%Europe/Berlin %790 %2005, 18:57

Ben, je kan ok gewoon je vorige post wijzigen hé ;).

Je bedoeld meerdere quotes in 1 reply denk ik? Ja nu je het zegt, zou inderdaad handiger geweest zijn :) Ben niet zo thuis in fori software, maar zal het onthouden.

Fatty Owl

%Europe/Berlin %728 %2005, 17:29

- Het is altijd sneller aan te geven waar je de variable vandaag haalt (this. is sneller dan niets aangeven)

In mijn boek staat dat het juist trager gaat als je this. erbijzet?

Dauntless

%Europe/Berlin %736 %2005, 17:40

Lijkt me wel heel vreemd! Welke pagina? (EAS 2.0 neem ik aan?)

Omdat als je this gebruikt, je juist zegt waar je var staat, terwijl anders flash moet gaan zoeken naar welke scope je bedoelt ...

Roenes

%Europe/Berlin %738 %2005, 17:43

als je er geen scope bij zet, zoekt flash dan niet automatisch in de huidige scope waar hij zich in bevind? Want als dat zo is, kan ik me voorstellen dat this ervoor trager is omdat het dan overbodige informatie is die verwerkt moet worden :)

Fatty Owl

%Europe/Berlin %757 %2005, 18:10

p 88 regel 4 gewone tekst (dus niet AS meegerekend ):)
Methods that make redundant use of this require more work to produce and take longer to read

Dauntless

%Europe/Berlin %770 %2005, 18:28

'k Denk dat hij bedoelt dat het echt letterlijk langer duurt om te lezen (dus als je als author over de code heengaat).

Ik heb ff een class bekeken die ik niet zo lang geleden gemaakt heb, zonder dit topic in m'n hoofd of zo, en eigenlijk gebruik ik 'this' geen enkele keer! Alé, wel een paar keer ( Delegate.create(this, onLoadEvent);, EventDispatcher.initialize(this); en als array : this[var] = "blaat").

Roenes

%Europe/Berlin %772 %2005, 18:32

Lees het stuk wat erboven staat ook nog eens ;)
However, using this when not required is redundant. For the sake of easier reading, many developers (and this book) avoid redundant uses of this. Even the single-line getArea() method is much less verbose without this.Dan komt er een klein stukje code. Het langer lezen slaat in dit geval dus echt op het lezen van een user, en niet van de compiler. Het gaat er gewoon om dat meneer colin beschrijft dat sommige dingen makkelijker te lezen zijn (voor mensen) als this er niet bij staat.

Dit stukje zegt dus niets over de snelheid van de compiler :)

Fatty Owl

%Europe/Berlin %778 %2005, 18:41

ok thx :) maaer wat dan met more work to produce?? ook de lezer?? dus de lezer moet meer werk produceren??

Dauntless

%Europe/Berlin %781 %2005, 18:45

Ahja, die moet toch elke keer 5 chars meer typen :D

oh,when?

%Europe/Berlin %996 %2005, 23:55

Ola, interessant gegeven dit. Ik heb er nog nooit van gehoord, maar als het zo is is het inderdaad een mogelijk argument om wel voor _root te kiezen. Ik vind het wel moeilijk aan te nemen van je die 30% (eigenwijze rotz*k ben ik ook he) dus als je ergens een benchmark hebt ben ik zeer geinterresseerd. Ik denk (zeker met fp8) dat je de boot in de toekomst wel gaat missen qua optimalisaties als je blijft hangen in oude 'oplossingen' moet ik wel zeggen. (probeer de fp8.5 eens anders met de zaken die je noemt? Ben erg benieuwd wat die er van maakt.)
Ik heb hier zo 1-2-3 geen benchmarks, maar het is ten tijde van de Flash 7 ontwikkeling bevestigd door oa Gary Grossman en wat engineers van het Flash Player team. Tis alweer een tijdje geleden (meer dan 2 jaar) dus ik moet echt in mijn archieven gaan duiken wil ik nog hard bewijs tevoorschijn toveren. In Flash 8.5 zijn deze bytecode hacks totaal nutteloos trouwens :) Maar das een verhaal voor een ander keertje