Verwijderd
[ Voor 6% gewijzigd door Verwijderd op 19-08-2005 22:47 ]
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Ik heb hier ook een php ebook liggen php 5 unleashed, maar een gewoon boek leest/leert gewoon lekkerder vind ik... (en boek was best duur en ben een jaar geleden maar tot de helft gekomen
)Als je PHP5 wil leren dan kun je inderdaad gewoon dat boek over PHP4 doorlezen, en dan het stuk over references en classes overslaan. Dan moet je dat onderdeel wel in dat PHP5 boek lezen, anders mis je een stuk basiskennis.:
Ik heb hier ook een php ebook liggen php 5 unleashed, maar een gewoon boek leest/leert gewoon lekkerder vind ik... (en boek was best duur en ben een jaar geleden maar tot de helft gekomen
Dus ik kan dat boek wel gewoon gebruiken en dan references en classes overslaan?
Omdat veel hosts nog niet overgestapt zijn, aangezien niet gegarandeerd wordt dat PHP5 100% backwards compatible is. Zelf gebruik ik ook nog PHP4, omdat ik er daarbij zeker van kan zijn dat het overal werkt. (Of in elk geval zekerder dan ik zou zijn al ik PHP5 zou gebruiken.
)
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Maar als heel veel mensen nog niet overgestapt zijn op PHP 5 is het dan als newbe wel beter om dat te leren dan? Of beter gewoon bij 4 blijven:
[...]
Als je PHP5 wil leren dan kun je inderdaad gewoon dat boek over PHP4 doorlezen, en dan het stuk over references en classes overslaan. Dan moet je dat onderdeel wel in dat PHP5 boek lezen, anders mis je een stuk basiskennis.
[...]
Omdat veel hosts nog niet overgestapt zijn, aangezien niet gegarandeerd wordt dat PHP5 100% backwards compatible is. Zelf gebruik ik ook nog PHP4, omdat ik er daarbij zeker van kan zijn dat het overal werkt. (Of in elk geval zekerder dan ik zou zijn al ik PHP5 zou gebruiken.
Heel leuk dat je dat onderbouwt.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Ik ben overtuigd! Ik ga lekker met mijn boek aan de gang, ook op php.net staat dat de verschillen niet zo heel groot zijn en dat daardoor migratie van 4 --> 5 vaak ook best simpel is...met name het object model is op de schop gegaan, maar goed het verschil is niet schokkend en ik ben maar newbe dus grote applicaties zal ik niet zo snel gaan schrijven
Het is gewoon vervelend dat je niet op een makkelijke manier php4 en php5 kan draaien onder apache.:
[...]
Heel leuk dat je dat onderbouwt.
Feit is dat de meeste hosters nog steeds achterblijven in PHP4, en je dus wel in PHP5 kan gaan programmeren, maar als je dan in aanraking komt met zo'n host, dan ben je wel mooi het haasje. Dan kun je al je code weer gaan aanpassen. Ik adviseer mensen die zelf niet hosten altijd om ofwel een host te zoeken die modern genoeg is om PHP5 te ondersteunen, ofwel om gewoon bij PHP4 te blijven. En zeg nou zelf, zoveel van die nieuwe features van PHP5 zijn nou ook weer niet essentiëel. Het enige dat werkelijk handig kan zijn in elke webapplicatie is het bestaan van exceptions, maar de rest mis ik echt niet. Voor de gemiddelde kleine webapp is OOP in PHP ook overdreven IMO. Vooral omdat de implementatie van OOP ook in PHP5 nog steeds niet helemaal perfect is, al is het een hele verbetering tegenover die van PHP4.
Eh, dat is gewoon mogelijk hoor. Moet je gewoon zowel PHP4 als PHP5 installeren, en vervolgens naast de vermelding dat .php door PHP4 geopend moet worden, een vermelding opnemen voor .php5 dat door PHP5 geparsed moet worden. Ik heb het zelf nooit gedaan, maar het schijnt nog geen 5 minuten werk te zijn.:
Het is gewoon vervelend dat je niet op een makkelijke manier php4 en php5 kan draaien onder apache.
Als .php gewoon door php4 gedaan werd en .php5 door php5, dan zouden er geen problemen op aarde meer zijn
Nu is het zo'n gedoe, want als hoster kan je ook niet zo even al je klanten op php5 overgooien, dan gaat er een hoop sneuvelen.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
. Plus nog wat Public / private / protected functies in Classes massaal (zoek + vervang) strippen en weghalen
< dit stukje webruimte is te huur >
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Echt? Ik hoor anders. Bij mijn weten moet een van beide dan onder CGI draaien in plaats van als Apache module en dat heeft toch wat gevolgen - diverse software gebruikt nl. mogelijkheden specifiek voor het gebruik als module.:
[...]
Eh, dat is gewoon mogelijk hoor. Moet je gewoon zowel PHP4 als PHP5 installeren, en vervolgens naast de vermelding dat .php door PHP4 geopend moet worden, een vermelding opnemen voor .php5 dat door PHP5 geparsed moet worden. Ik heb het zelf nooit gedaan, maar het schijnt nog geen 5 minuten werk te zijn.
"Technological advancements don't feel fun anymore because of the motivations behind so many of them." Bron
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Thx, ga ik doen!:
@TS: het lijkt mij, vooral met oog op de toekomst ook, dat je je verdiept in PHP5. Nu is de taal op veel puntjes misschien niet perfect c.q. streng/conform genoeg -dat de taal volgens mij ook zo toegankelijk maakt en populair- het zorgt er wel voor dat de taak gedaan wordt. Goed programmeren, ach, de functionaliteit die een taal biedt helpt tot op zekere hoogte; de persoon die de code levert heeft er meer over te zeggen
Wat betreft je aankoop van een PHP4 boek, PHP5 verschilt hem het meest in classen en accesibility modifiers (waar in PHP4 altijd public uitgegaan wordt). Voor de rest is gewoon dezelfde taal
Dit gedeelte kun je dan ook beter niet lezen zoals al eerder is gezegd, om het fout leren te voorkomen
Hmm.. ja, waarschijnlijk wel ja. Ik moet zeggen dat ik van die verschillen te weinig af weet om te kunnen oordelen of het a) echt een praktische beperking is of wel mee valt en b) erg veel impact heeft op de server (d.w.z. is CGI veel langzamer of niet?)
Goed mogelijk dat deze wijze toen ook al werkte, maar dat is niet de manier die PHP.net in zijn manual aangeeft:
Dat is bij 4 -> 5 kennelijk niet mogelijk. Dus zou het zéér wenselijk zijn voor de PHP-crew te documenteren hoe het toch (min of meer) kan en bijvoorbeeld wat mensen van CPanel daarin te begeleiden..
Conclusie: dat zou van "PHP zijde" zo langzamerhand eens vlotgetrokken moeten worden.
Verwijderd
.. Voor mensen die ze niet gebruiken, is PHP4 zeker nog wel voldoende.
Allereerst, accessibility mogelijkheden geven de programmeur de kans om principes als encapsulatie en code-by-contract beter in praktijk te brengen. Dit was door het ontbreken en impliciet uitgaan van public bij PHP4 iets waar ik me dermate aan stoorde. Nu is het mogelijk itt php4 een betere classen specificatie op te stellen en onderscheid te maken tussen genoemde en implementatie componenten; hello encapsulation / code by contract
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
| interface Figure { //.. } class Rectangle implements Figure { //.. } class Circle implements Figure { //... } class Test { public function draw(Figure $f) // <- typehinting ;) { $obj = null; /** * woohoo, polymorphisme / dynamic binding ;) * Het kan zijn dat je f niet wil behandelen als zijnde supertype Figure, maar als een subtype Rectangle danwel Circle, afhankelijk van waar het object dat meegestuurd wordt naar referenced. * Dan zul je dynamisch moeten typechecken en -casten, naar waar het object f daadwerkelijk naar referenced. */ if ($f instanceof Rectangle) $obj = (Rectangle) $f; else if($f instanceof Circle) etc... } } |
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Misschien moet je ook even de comment verder lezen
[ Voor 37% gewijzigd door prototype op 20-08-2005 23:41 ]
Daar heb je een goed punt, maar het was even een snel voorbeeld; draw was in deze context misschien een ongelukkige naam voor de methode. Ik wilde meer typehinting even aan de orde brengen
Bovendeien is de methode die je suggereert nog mogelijk in dit simpel voorbeeldje, door draw methode aan de interface van figure toe te voegen en deze in de draw methode van Test te invoken op f.f kan in dit voorbeeld referencen naar een object die subtype is van Figure, maar wordt ongeacht dat behandeld als supertype Figure; de methoden die gespecificeerd staan in interface Figure zijn enkel toegankelijk voor de gebruiker op het object, ongeacht het feit dat het subtype waar het object naar referenced misschien over meer methoden beschikt.
[ Voor 47% gewijzigd door prototype op 21-08-2005 01:00 ]
Voor het voorbeeld zou ik het dan toch achterwege laten. Je moet zo proberen te designen dat casten weinig of niet hoeft. Hier had ik laatst ook een topic over geopend.:
[...]
Daar heb je een goed punt, maar het was even een snel voorbeeld; draw was in deze context misschien een ongelukkige naam voor de methode. Ik wilde meer typehinting even aan de orde brengen
Het is dan niet zo dat f ook werkelijk wordt behandelt als een Figure, je kunt f alleen gebruiken via de interface van Figure, of Figure nu ook werkelijk een pure interface is of een class.
Je kunt wel typehinten, in dat geval moet je een object geven die de gegeven interface ondersteund. Casten naar een andere interface kan niet en is zelfs niet nodig, je kunt iedere method aanroepen die je wilt. Op zich niet echt netjes, maar het scheelt je in dit geval wel een cast.Okay, scrap that, ik heb PHP iets teveel crediet gegeven op gebied van typecasten door ervanuit te gaan dat dit hetzelfde gaat als in java; niet dus na een zojuist uitgevoerde test, dit is namelijk nog steeds gelimiteerd tot de types die PHP als zijnde primitief beschouwd... vrij logisch opzich, maar ik was even vergeten dat PHP typejuggled en dus eigen gedefinieerde referentietypen (nog?) niet ondersteund. My bad
Er zijn, zoals Michali hierboven al zegt, ook wat betreft references wat dingen veranderd. De werking is hetzelfde, maar sommige dingen die in PHP5 standaard references zijn of opleveren, waren/deden dat in PHP4 niet. Als je dus uit een PHP4-boek het stukje over references hebt doorgelezen terwijl je PHP5 wil leren, dan zit je uiteindelijk met halve waarheden en niet kloppende gedachtegangen in je hoofd, lijkt me onnodig.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Ik begin er aan te geloven dat ik nooit met het voorbeeld had moeten beginnen, aangezien het punt waar kritiek op is, juist net hetgene is waar het niet om ging
; ik weet dondersgoed dat je moet oppassen met casten van referencetypen (is zelfs niet mogelijk in PHP) en dat je dit gematigd dient te doen, omdat het flexibiliteit aantast; je bent dan te specifiek en coupled classen en creeert daardoor (vaak onnodig) dependencies. Dit is bekende koek, maar dat was niet mijn doel met het voorbeeld. Ik zal dergelijke dingen in het vervolg er expliciet bij zetten. Heb ik dan anders beweerd?
(Voor de duidelijkheid: f kan een subtype van Figure referencen, maar gebruik voor clients geschied via het interface van Figure; het object wordt dan dus door de client gebruikt als zijnde type Figure, aldus mijn javaboek Helaas gaat dit niet op voor PHP, wat ik aanvankelijk wel dacht.).Eerder casten naar een andere referentietype (zij het sub of super) kan niet in PHP.
Het is idd niet netjes, maar je kan met zekerheid iig zeggen dat de methoden die de interface specificeert terug moeten komen in het object die meegestuurd is via de typehint. Dat is nog altijd een verbetering tov geen uitspraak erover kunnen doen zoals in PHP4 (of het kan wel, maar dan heel omslachtig)
[ Voor 4% gewijzigd door prototype op 21-08-2005 12:57 ]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| <?php interface A { public function func_a(); } class B implements A { public function func_a() { echo "B->func_a()\n"; } public function func_b() { echo "B->func_b()\n"; } } class C { public static function call_b( A $a ) { $a->func_a(); $a->func_b(); } } $b = new B(); C::call_b( $b ); ?> |
1
2
3
4
5
| Content-type: text/html X-Powered-By: PHP/5.0.3 B->func_a() B->func_b() |
Dan begrijpen we elkaar:
Heb ik dan anders beweerd?
Je legde het ook meer uit in taal specifieke termen en ik probeerde het wat algemener te houden. Mischien dat ik het daarom ook verkeerd begreep.
[ Voor 14% gewijzigd door Michali op 21-08-2005 14:29 ]
Als je onze gezamelijke replies nog eens leest zul je zien dat ze qua inhoud niet veel verschillen van de jouwe
Eh? Eerder bij methode aanroep wordt de meegegeven argument expressie ge-evalueerd op referentietype waarde zoals die gespecificeerd staat in de typehint.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| <?php error_reporting(E_ALL); class A { } class B { } class Foo { /** *... *@require $bla instanceof A *... */ function bar( $bla ) { assert(is_a($bla, "A")); print("Meegegeven argument is van type A"); } } $a = new A(); $b = new B(); $f = new Foo(); $f->bar($a); $f->bar($b); //Dit geeft een assertion warning icm error_reporting aan, maar voert bar verder nog wel (helaas) uit. De bewering dat de argument van type A is, klopt dan niet meer, maar ja, de preconditie is dan ook niet nagekomen. ?> |
Aanvankelijk dacht ik dat PHP net als java ook referentietypen kon casten (zie mijn 2e reply in dit topic), maar dit is gelimiteerd tot de typen die PHP als primitieven beschouwd. Wat je zegt is dus niet mogelijk, en dat is opzich achteraf gezien ook wel logisch aangezien PHP weaktyped is en geen notie heeft van referencetypes.
Ik zie het nut niet in om een bepaalde taal eerst 'fout' te leren (respectievelijk de PHP4 way), om vervolgens te weten te komen dat het eigenlijk anders moet in PHP5. Wel zie ik het nut in om een totaal andere taal te leren om je meer bekend te laten raken met OO principes; een hogere programmeertaal als java/C#/etc.. biedt hierbij uitkomst, en PHP neigt hier ook steeds meer naartoe; support voor packages die binnenkort in PHP zitten vind ik wel fijn, maar ik zou het toffer vinden als ze eens wat doen aan method overloading. Wat ze nu als overloading beschouwen vind ik ronduit schandalig, ja, dat 'simuleren' heb ik het over
[ Voor 18% gewijzigd door prototype op 21-08-2005 15:15 ]
Hehe, dat zeg ik nou ook niet. De principes van OO staan natuurlijk los van een specifieke taal, maar veel talen bieden ondersteuning voor het in de praktijk brengen. OO is dan ook eerder een gereedschap, een manier van denken, maar niet een religie.:
Het is imo veel beter om een algemeen boek te lezen om beter bekend te raken met OO princiepes. Het gaat immers om de princiepes en niet om de taal. In de ene taal is het wat moeilijker om ze toe te passen dan de ander, maar het is vaak wel mogelijk. Een boek waar ik echt veel van geleerd heb is "Design Patterns Explained".
Maar we geraken een beetje erg offtopic zo, dus weer ontopic
Er zijn genoeg voorbeelden al genoemd in dit topic die een 'fijne' OO implementatie in de weg staan, simpelweg omdat de taal niet een notie heeft van... maar goed, misschien dat > PHP5 wel beterschap zal bieden Blijkbaar begrijp je mij dan verkeerd, maar dat is juist wat ik bedoel... Toch wil ik je nog even op het volgende wijzen:
Ik geef PHP4 leren ook niet als middel om PHP5 te leren. Ik zeg dat dit nog eens handig van te pas kan komen omdat je zo wellicht beter oude code van anderen kunt begrijpen. Als beginner ga je natuurlijk op zoek naar voorbeeldcode en als je dan plots PHP4 OO tegen komt, weet je dat tenminste ook te herkennen en te lezen.
Daar ga ik ook niet van uit bij mijn voorbeeld
Ik weet niet of je bekend bent met het code by contract principe, maar daarbij ken je specifiek verantwoordelijkheden toe aan respectievelijk client en server. Je stelt als het ware een contract op tussen client en server, waar een client zich aan zijn eind moet houden (preconditie) om ervoor te zorgen dat de server zich ook aan zijn eind van het contract houdt (postconditie). De client is in dit geval dan niet zijn eind van de deal nagekomen, en de server hoeft dat dan op zijn beurt ook niet te doen; het contract is zo te zeggen ontbonden.[ Voor 14% gewijzigd door prototype op 21-08-2005 20:49 ]
Erm, daar zijn die javadoc/phpdoc tags eigenlijk niet voor bedoeld; ze dienen respectievelijk een beschrijving te geven van de parameter en over de return waarde. Bovendien ga je ervan uit dat postcondities dan gebonden zijn aan returns (i.e. queries), en dat is _NIET_ het geval. Postcondities verzekeren de client dat wanneer er aan de preconditie is voldaan, de postconditie ook nagekomen wordt. Dit kan b.v. ook betrekking hebben op de staat van een object. Pre- en postcondities wordt uit conventie overwegingen vaak aangeduid met een customtag; @require en @ensure tags b.v. De 'taal' waarmee je de pre- en postcondities in formuleert is eigenlijk informeel, maar het is vuistregel dat je dit zo strak en contextvrij loos doet; liever niet in een beschrijving dus, maar in een pseudo expressie. Hierbij kun je voor statechanges evt old gebruiken om het object aan te duiden VOORDAT de methode is aangeroepen.:
Dank voor de uitleg. In feite heb ik dit al altijd toegepast met phpDoc waarbij ik de pre en post condities in de @param en @return tags plaatste. Type hinting gebruik ik zelf ook alleen maar als handigheidje dat runtime kan aangeven of ik wel aan het "contract" voldoe. Nu weet ik voor dit alles weer een leuke benaming.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| <?php class Counter { private $count; //invariant: count >= 0 public function __construct() { $this->count = 0; } public function count() { return $this->count; } /** * @require this.count() >= 0 * @ensure this.count() > 0 && this.count() > old.count() */ public function increment() { $this->count++; } /** * @require this.count() > 0 * @ensure this.count >= 0 && this.count() < old.count() */ public function decrement() { $this->count--; } } ?> |
[ Voor 9% gewijzigd door prototype op 22-08-2005 20:49 ]
/u/48908/avatar.JPG?f=community){kind=avatar}
/u/107051/jeroenmadtrix60.png?f=community)
/u/24332/garfield-icon-by-negotiator.png?f=community){kind=icon}
:strip_icc():strip_exif()/u/27548/php_60.jpg?f=community)
:strip_exif()/u/23403/wicky55.gif?f=community)
:strip_icc():strip_exif()/u/146003/48295-60-60.jpg?f=community)
:strip_icc():strip_exif()/u/26612/droptikkels_icon.jpg?f=community){kind=icon}
:strip_exif()/u/72870/crop5db2a0081b965.gif?f=community)
/u/34186/crop62e07d174532d_cropped.png?f=community)
:strip_exif()/u/28900/sharingan.gif?f=community)
:strip_icc():strip_exif()/u/52966/DSC04760%2520-%2520ProfilePic2%252060x60.jpg?f=community)
:strip_icc():strip_exif()/u/59957/got-icon.jpg?f=community){kind=icon}