[taal] engels: rechtstreeks
Pagina: « vorige 1 2 3 volgende »
Haha... lol. Maar die getIterator heb ik toch nodig om door de class property te loopen? Die getIterator wordt automatisch aangeroepen, zodra je gaat loopen. Daarom is mijn stelling dat het onzin is om die iterator apart aan te roepen. Snap je mijn gedachtengang?
Daarnaast, in de getIterator method kan ik precies aangeven welke property wil doorlopen. Het enige wat ik onzinnig vind als je handmatig de getIterator method aan gaat spreken terwijl dat niet nodig is.
Code (php)
Dat eerste voorbeeld vind ik dus onzinnig. Maar het zal wel aan mij liggen.
Ik heb nog steeds de indruk dat je de IteratorAggregate interface gebruikt terwijl de Iterator interface meer op zijn plaats is. Waar aggregeer je objecten? Dáárvoor is de IteratorAggregate interface bedoeld. Aggregeer je geen objecten, gebruik dan de Iterator interface.
Volgens mij is de IteratorAggregate precies bedoeld voor wat ik wil, namelijk door properties heen loopen. Kijk anders even hier:
http://www.php.net/manual/en/class.iteratoraggregate.php
Ik snap niet wat ik volgens jou niet goed doe, maar hoor graag je reactie.
Als je de Iterator interface implementeert, moet je next en previous en weet ik het wat voor methods implementeren in je class. Bij de IteratorAggregate interface hoef je alleen maar aan te geven welke property je wilt kunnen loopen en verder niks. Nogmaals zie ook http://www.php.net/manual/en/class.iteratoraggregate.php
In het 1e voorbeeld kun je "return new ArrayIterator($this);" ook vervangen door bijv. "return new ArrayIterator($this->some_property);".
Ik zie niet zo goed wat ik dan fout doe, of ik begrijp niet wat je bedoelt.
Als ik de Iterator interface implementeer maak ik het mezelf toch veel lastiger omdat ik een hoop methods moet implementeren. Nu hoef ik alleen getIterator te implementeren en ik ben klaar. Wat doe ik dan verkeerd volgens jou?
Met een foreach voer je een iteratie uit, maar niet elke iteratie is een foreach. Je mag de argumentatie dus niet omkeren. Alle honden zijn dieren, maar niet alle dieren zijn honden.
De methode getIterator() heeft een bestaansrecht wanneer je binnen het geaggregeerd object $bibliotheek voor de gehele collectie boeken een andere iteratie uitvoert dan voor de hoofdstukken van één boek. (Abstract voorbeeld: de boeken zouden alfabetisch op titel kunnen worden geïtereerd en de hoofdstukken numeriek op hoofdstuknummer, zelfs al hebben hoofdstukken ook titels.)
Je maakt nu een soort negatieve non-keuze voor een interface: je kiest de IteratorAggregate interface omdat die maar één methode heeft die je niet wilt implementeren en de Iterator interface meerdere methoden heeft die je niet wilt implementeren. Laat die interfaces dan links liggen en schrijf zelf een schone interface met methoden die je wél wilt implementeren.
Ik wil maar een ding, en dat is met een object kunnen loopen door een (gespecificeerde) class property.
Dus stel ik heb een data class met een data property, dan wil ik door deze data property kunnen loopen.
Waarom zou IteratorAggregate niet de juiste oplossing zijn?
Ook hier zijn ze er positief over: http://fabien.potencier.org/article/45/iterator-or-iteratoraggregate
Dus ik snap niet wat je wil zeggen. Ik begrijp dát je me iets wil duidelijk maken, maar ik heb geen idee wat.
Ik vind dat minimalisme een non-argument, want het aantal methoden of regels code zegt niets over de geschiktheid van een interface.
Mijn punt is dat je niet iets tweederangs moet lenen als zelf iets eersterangs bouwen beter is. Zoek een interface die de data-objecten precies zo afhandelt als jij wilt. Bestaat die interface nog niet, dan schrijf je deze zelf. Maar ga niet iets lenen dat "ongeveer in de buurt komt". Dat doe je nu eigenlijk wel: je implementeert een interface met maar één methode, maar die ene methode wil je niet implementeren. Dan is de interface dus niet geschikt voor je doel.
Als het uitvoeren van een loop met een foreach echt je enige doel is, kun je ook nog overwegen om helemaal geen interface te implementeren.
Dat is niet wat ik zeg. Die methode hoort erin, alleen ik wil voor mezelf aangeven dat ik die niet handmatig moet aanroepen omdat dat onzin is. Dit is iets anders dan wat jij nu suggereert.
>> Mijn punt is dat je niet iets tweederangs moet lenen als zelf iets eersterangs bouwen beter is.
Maar dat kan toch helemaal niet? Om door een specifieke property van een object te loopen heb je de Iterator of IteratorAggregate interface nodig. Ik kan toch niet tegen PHP zeggen dat ie een bepaalde method moet aanroepen op het moment dat ik een object in een loop gooi?
>> Dat doe je nu eigenlijk wel: je implementeert een interface met maar één methode, maar die ene methode wil je niet implementeren. Dan is de interface dus niet geschikt voor je doel.
Nogmaals, die interface is prima geschikt, alleen ik wil voorkomen dat ik per vergissing handmatig die getIterator method aanroep, omdat dat geen enkele toegevoegde waarde heeft. Mooier zou het zijn geweest als je die method private of protected kon maken, maar dat kan helaas niet.
>> Als het uitvoeren van een loop met een foreach echt je enige doel is, kun je ook nog overwegen om helemaal geen interface te implementeren.
Dat kan ook, alleen als je dan meerdere class properties hebt, dan worden die ook meegenomen in de loop en dat is niet de bedoeling.
Waarom zou je het dan ooit aanroepen? Plus het aanroepen kan geen kwaad...
Okay, nu worden we al concreter. Je wilt een data-object in een foreach steken waarmee je gericht maar één specifieke property ophaalt, niet alle andere properties? Geef eens een voorbeeld?
>> Waarom zou je het dan ooit aanroepen? Plus het aanroepen kan geen kwaad...
Het kan inderdaad geen kwaad. Maar het kan zomaar zijn dat ik over een jaartje ben vergeten (alhoewel... na deze discussie) dat het zinloos is om eerst die method aan te roepen en dan te gaan loopen, omdat ik gewoon direct het object kan loopen. Daarom wil ik in het commentaar zetten dat ik die method niet rechtstreeks moet aanroepen.
@Ward:
>> Okay, nu worden we al concreter. Je wilt een data-object in een foreach steken waarmee je gericht maar één specifieke property ophaalt, niet alle andere properties? Geef eens een voorbeeld?
Dat zeg ik toch de hele tijd al :-(((
Zie hier het voorbeeld dat ik eerder al gaf:
http://www.phphulp.nl/php/forum/topic/taal-engels-rechtstreeks/94199/1/#675801
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?php
class ArrayWrapper implements \IteratorAggregate
{
private $array = array();
public function __construct(array $array)
{
$this->array = $array;
}
public function getIterator()
{
return new \ArrayIterator($this->array);
}
}
$array = new ArrayWrapper($data);
foreach ($array as $key => $value)
{
// doe iets met key en value
}
?>
class ArrayWrapper implements \IteratorAggregate
{
private $array = array();
public function __construct(array $array)
{
$this->array = $array;
}
public function getIterator()
{
return new \ArrayIterator($this->array);
}
}
$array = new ArrayWrapper($data);
foreach ($array as $key => $value)
{
// doe iets met key en value
}
?>
Ik snap alleen niet wat je daarmee wil zeggen.
>> dus dan wordt de vraag of je wel een OOP-wrapper wilt maken door een gewone array in een array-object te verpakken.
Ik denk het dus wel. Ik zie de DataCollection als een object, waarbij ik waardes kan setten en getten. En ik wil er doorheen kunnen loopen. Maar zijn er volgens jou dan betere alternatieven?
Vergelijk het anders met een integer. Dat doe je ook liever zo:
$onvoldoende = 5;
dan zo:
$data = 5;
$onvoldoende = new IntegerObject($data);
"iets OOP gemaakt dat al bestaat"
Je bedoelt daarmee een normale array?
Dat is toch geen OOP? Een array kan toch zowel OOP zijn als niet?