[BC3] [php] OOP

[Verwijderd]

Hallo allemaal,

ik ben me even aan het interesseren voor OOP in PHP.
Nu vroeg ik me alleen sterk af, wat is het voordeel van Classes tegenover Functies.
Ik hoop dat iemand me dit met een concreet voorbeeld uit kan leggen.
Wat ik me ook af vraag, wat is er, behalve alles, zoal mogelijk met classes.

Alvast bedankt!

[maartenvdv737]

Dit wil ik dus ook heel graag weten. Ik heb er al wel redelijk wat over gelezen, maar niet veel wijzer geworden.

Danny> hier heb jij dus ff niets aan

[Verwijderd]

Tsja, wat het voordeel er van is? Geen idee.

Ik gebruik het omdat het overzichtelijk is. Wat ook best makkelijk is, is dat je variables binnen classes kunt gebruiken zonder het via ''global'' aan te geven in de function. Gewoon $this->blaat=''zut''; en je kunt ''t overal gebruiken.

Eigenlijk is een class niet meer dan een partij functions.

[Verwijderd]

aha, bij veel voorbeelden zie ik btw staan $this->xxx, is this een predefined var door php, of staat dat gewoon leuk? Tnx.

[Verwijderd]

T''is gewoon overzichtelijker voor jezelf, om alles in groupen onder te brengen zeg maar.

Hier wat linkjes:
http://www.phpbuilder.net/columns/mark20000727.php3
http://www.phpbuilder.net/columns/luis20000420.php3
http://www.phpbuilder.net/columns/rod19990601.php3

[wasigh]

this refereert aan het actieve object(aan zichzelf dus) en wordt naar mijn weten veel gebruikt in OO, java heeft het in ieder geval ook.

Verder is PHP niet echt Object-Orientated.

En class en een Function zijn echt erg verschillende dingen.

Het uitgangspunt van OOP is dat je werkt met object met eigenschappen(attributen ook wel variabelen) en methods(functies)

Nu kun je bijvoorbeeld een class auto maken. met de attributen: kleur, aantal wielen, vermogen, topsnelheid.
En met de methodes: geefGas(), rem(). tankBenzine()

(beetje vreemd voorbeeld misschien)

En wat is nu het leuke?
Stel je wilt een programma maken die 5 auto''s beheert()dan maak je 1 keer de code voor je auto, die stop je in een class. en kun je 5 objecten van een auto maken. En daar de variabelen vervangen, en hun functies uitvoeren.


Dit is "the basic" van oop. Php is zoals al eerder op dit forum vermeld niet echt oop.
Het mist namelijk: overerving, public, private en protected identifiers(?),
het is dus geen OOP taal, maar een taal met OOP mogelijkheden al zijn ze beperkt.
En ik snap persoonlijk ook niet waarom je het OOP zou willen.

Hopelijk ben ik duidelijk genoeg?

[brammetje]

Op woensdag 04 april 2001 20:34 schreef wasigh het volgende:
[edit: ingekort]

Hopelijk ben ik duidelijk genoeg?

ja, duidelijk, dus niet wazig

[Verwijderd]

waarom opp?

ik ben bezig met een nogal groot project, en wil daarom de code overzichtelijk houden, vandaar opp.

[tomato]

Het valt me op dat hier veel mensen over OOP praten (niet per se in deze thread en ook niet persoonlijk bedoeld) en classes gebruiken, maar eigenlijk geen idee hebben waar ze mee bezig zijn. Moet wel toegeven dat PHP niet echt de perfecte (understatement) taal is om met OOP te beginnen.

[wasigh]

. Moet wel toegeven dat PHP niet echt de perfecte (understatement) taal is om met OOP te beginnen.

Inderdaad. Oop is niet moeilijk, Het is meer een manier van denken en het doorkrijgen.

Java of smalltalk zijn goede talen om OOP te oefenen.

Op woensdag 04 april 2001 21:04 schreef dannydude het volgende:
waarom opp?

ik ben bezig met een nogal groot project, en wil daarom de code overzichtelijk houden, vandaar opp.

Is niet echt nodig, Als je geen gebruik maakt van objecten zou ik oop afraden(in php)

[Verwijderd]

wasigh: Oop is niet moeilijk, Het is meer een manier van denken en het doorkrijgen. Java of smalltalk zijn goede talen om OOP te oefenen.

Of Python.

Als je geen gebruik maakt van objecten zou ik oop afraden(in php)

OOP zonder objecten is een interessant concept.

[wasigh]

Op woensdag 04 april 2001 21:38 schreef Arien het volgende:
wasigh: Oop is niet moeilijk, Het is meer een manier van denken en het doorkrijgen. Java of smalltalk zijn goede talen om OOP te oefenen.

Of Python.

Ik vroeg me al af hoe lang het zou duren...
Ze zouden je aan moeten nemen bij het Pyton promotie team

Als je geen gebruik maakt van objecten zou ik oop afraden(in php)

OOP zonder objecten is een interessant concept.

Wat ik bedoelde: Als je Oop(classes) alleen gerbuikt voor het overzicht en niet van plan bent meerdere objecten aan te maken. Is het in php alleen maar overhead(imo)

[demonite]

OO is gewoon klote in PHP..

je kunt het echt voor niets meer gebruiken als het verzamelen van functies want het werkt voor geen ene meter... en van de fout meldingen wordt je al helemaal niets wijzer als je classes gebruikt.

nee, php is best leuk... maar als je overzichtelijk je functies wil opbergen.. maak dan maar gewoon meerdere files aan!

lang leve java/jsp/ejb

[Verwijderd]

wasigh: Ik vroeg me al af hoe lang het zou duren. Ze zouden je aan moeten nemen bij het Pyton promotie team

Dan zouden ze dat ook kunnen doen voor de promotie teams van Perl, C/C++, Java, etc. Het hangt er eigenlijk vanaf waar het over gaat. Python is qua ontwerp erg goed doordacht en daardoor heel eenvoudig te leren (zonder dat het een toy language is), vandaar de opmerking.

Wat ik bedoelde: Als je Oop (classes) alleen gerbuikt voor het overzicht en niet van plan bent meerdere objecten aan te maken.


Ik snap niet helemaal wat je hier mee bedoelt...

[Genoil]

Nou omdat ik al OO progde in C++, Java en zelfs in Lingo, dacht ik dat het bij PHP voor mij ook de gemakkelijkste manier was om te werken. Maar ik vind de OOP implementatie in PHP echt suckend. Waarom?

* onbreken van verplichte typedefs (algemeen PHP-nadeel imho)
* member vars alleen bereikbaar vanuit memberfuncties via $this->
* geen overloading, overriding
* geen mult. inheritance (ok, da''s niet zooo erg)
* persistent objects alleen mogelijk via sessions, schijnt met objecten niet erg betrouwbaar te zijn

etc.

[Verwijderd]

Laat ik ook eens hip quoten

Genoil: * member vars alleen bereikbaar vanuit memberfuncties via $this->

Jawel, via $classname->var (of begrijp ik nu niet wat je bedoeld?)

[tomato]

[nielsonline]: Jawel, via $classname->var (of begrijp ik nu niet wat je bedoeld?)

Dat is dus ook een slechte OOP ''feature'' van PHP, dat dat altijd kan op die manier.

[Verwijderd]

Goede voorbeelden van classes zijn dingen als

- database (kan je makkelijk wisselen van bijvoorbeeld MySql naar Oracle, nu maar hopen dat Femme dat ook heeft gedaan, kan ie lekker makkelijk overstappen op een andere database, heel veel mensen willen dat namelijk graag, vandaar )
- templates (als je later de interne werking van je template wil veranderen dan hoef je de code niet te verbouwen)
- in en uitloggen van bezoeker (zelfde verhaal als bij de templates)
- en nog meer dingen die je niet alleen in een specifiek project gaat gebruiken, maar die gewoon heel allround zijn, en die je ook gaat gebruiken voor andere projecten, nog een voorbeeld is error-handling.

[Verwijderd]

tomato: Dat is dus ook een slechte OOP ''feature'' van PHP, dat dat altijd kan op die manier.

Waarom slecht? Ik vindt het wel handig. Binnen classes werk ik altijd met dat soort dingen. Bijvoorbeeld in m''n session class gebruik ik een array met alle session variables. En met deze ''slechte'' feature kan ik die ook buiten de class gebruiken.

[Verwijderd]

dennis@wacky: precies, dat bedoel ik. Ik heb sessions, templates, db functions in een class, en nog een class met wat standaard dingen.

[Ritch]

Op donderdag 05 april 2001 00:26 schreef [nielsonline] het volgende:
Waarom slecht? Ik vindt het wel handig. Binnen classes werk ik altijd met dat soort dingen. Bijvoorbeeld in m''n session class gebruik ik een array met alle session variables. En met deze ''slechte'' feature kan ik die ook buiten de class gebruiken.

Ja maar dat is nou juist niet OO!

[Verwijderd]

Ik ben op het moment bezig met een validator class, gewoon om allerlei soorten data types te checken voor verborgen shit enz..

Voor dat soort dingen zijn classes echt handig, maar voor echt OOP programmeren is PHP gewoon als taal niet geschikt, ze hebben dat proberen een beetje te fixen door het toevoegen van classes. Alleen echt helemaal toppie zal het nooit worden vrees ik.

Maar daarom gebruiken ook zoveel beginners PHP, OOP programmeren is namelijk aardig wat moeilijker dan php-op-beginners-niveau-kijk-ik-kan-"Hello World"-laten verschijnen-niveau.

[mbravenboer]

Het mooiste van object orientatie is dat je objecten kan gebruiken onafhankelijk van de implementatie.

Hierdoor kan je polymorph (is dat goed nederlands ) werken. Hiermee bedoel ik dat je categorien van objecten kan behandelen via dezelfde interface. In Java heb je bijvoorbeeld de interface Comparable. Als een klasse (bijvoorbeeld een String, Integer of een willekeurig domein object) deze interface implementeert kan hij gesorteerd worden met een polymorph sorterings algoritme wat werkt via de Comparable interface.

Uiteraard heb je dan nog de wel bekende verberging van variabelen etc, maar ik denk dat vooral het werken met inheritance en interfaces de meest krachtige aspecten van een OO taal zijn.

Tegenwoordig zie je ook steeds meer frameworks (zoals bijvoorbeeld DOM, SAX, JDBC, CORBA) gedefinieerd als een verzameling van in interfaces zonder een implementatie. Je kan nu implementatie onafhankelijk werken met zo''n framework. De implementatie kan zeer eenvoudig gewisseld worden, zonder dat dit een aanpassing van je code vereist.

Als je goed OO werkt bereik je een hele lage lokale complexiteit. Regelmatig zal je je afvragen waar er nu eigenlijk iets begeurt. Door de goede capaciteiten op het gebied van black-box reuse kan je eenvoudig ingewikkelde systemen maken zonder dat je code voortdurend een hoge complexiteit heeft. Vaak is het zo dat je design slecht is als je code wel complex is.

[dusty]

Op woensdag 04 april 2001 21:38 schreef Arien het volgende:
OOP zonder objecten is een interessant concept.

Ehh valt dan niet de eerste O van de afkorting af ? OP programmeren ?

[dusty]

Een term wat ik tot nu toe mis in deze thread : Data Encapsulation.

[wasigh]

Op woensdag 04 april 2001 21:53 schreef Arien het volgende:


Wat ik bedoelde: Als je Oop (classes) alleen gerbuikt voor het overzicht en niet van plan bent meerdere objecten aan te maken.


Ik snap niet helemaal wat je hier mee bedoelt...

Nou, er zijn makkelijker manieren in PHP in functies te ordenenen. En ik zou daar geen classes voor gebruiken. Pas als je ook echt meerdere objcten van iets aan gaat maken, bijvoorbeeld 2 ftp verbinddingen ofzo. Dan zou ik wel die ftp verbinding in een class bouwen.

Op donderdag 05 april 2001 00:26 schreef dennis@wacky het volgende:
Goede voorbeelden van classes zijn dingen als

- database (kan je makkelijk wisselen van bijvoorbeeld MySql naar Oracle, nu maar hopen dat Femme dat ook heeft gedaan, kan ie lekker makkelijk overstappen op een andere database, heel veel mensen willen dat namelijk graag, vandaar )
- templates (als je later de interne werking van je template wil veranderen dan hoef je de code niet te verbouwen)
- in en uitloggen van bezoeker (zelfde verhaal als bij de templates)
- en nog meer dingen die je niet alleen in een specifiek project gaat gebruiken, maar die gewoon heel allround zijn, en die je ook gaat gebruiken voor andere projecten, nog een voorbeeld is error-handling.

Dit zijn in mijn ogen dingen die je ook gewoon in fucnties kan bouwen en waar je eigenlijk geen classes voor nodig hebt. Tenminste zo doe ik het. Ik heb gewoon bestanden zoals databaseconnectie.php met een functie connectDatabase(). En die import ik gewoon. Als ik nu naar een andere database wil. hoef ik alleen dat bestand maar aan te passen.

Wat in mijn ogen ook een goede reden is om geen OOP in PHP te gebruiken is de snelheid.
Bij Java wordt altijd gezeurd dat het te langzaam is. Maar dit komt vooral door de overhead die er nodig is bij objecten. Als je geen objecten gebruikt in java. Is het ongeveer net zo snel als c++(jdk 1.3)

Ik denk dat iedereen die ervaring heeft met een (echte)OOP taal, weet dat php "minder fijn is" op OOP gebied:)


BTW: zoals ik ook al een keer op LA heb gezegd. Is het probleem hier met de database erg makkelijk te voorkomen. Mensen gaan snel roepen dat er een nieuwe database moet komen. Maar men zal eerst de code eens onder handen moeten nemen.

Zo maken ze hier voor elke pagina-aanroep een dynamische pagina aan (= +- 3 queries)
Terwijl er erg vaak dezelfde data wordt teruggegeven.
Stel ze zouden cachen, (in een tussenformaat) en alleen wanneer er een post of een edit komt, slaan ze een nieuw bestand op. Dan ontlast dat de database voor 50%
[maar ik zal weer ontopic gaan >:)]

[bloody]

Dit is "the basic" van oop. Php is zoals al eerder op dit forum vermeld niet echt oop.
Het mist namelijk: overerving, public, private en protected identifiers(?),

xcuse me! heeft wel degelijk overerving!

edit:
quoten mislukte:)

[wasigh]

Op donderdag 05 april 2001 10:44 schreef bloody het volgende:

[..]

xcuse me! heeft wel degelijk overerving!

edit:
quoten mislukte:)

Geef maar eens een (werkend) voorbeeld dan.
(ik heb deze info ook maar uit mijn boek, en er zijn genoeg andere argumenten waarom PHP niet OOP is)

[wasigh]

Op donderdag 05 april 2001 10:51 schreef bloody het volgende:

[..]

Je hebt helemaal gelijk

Dit doet alleen niets af aan het feit dat Php niet echt een OOP taal is..

[bloody]

Op donderdag 05 april 2001 10:54 schreef wasigh het volgende:

[..]

Je hebt helemaal gelijk

Dit doet alleen niets af aan het feit dat Php niet echt een OOP taal is..

agree!

[dusty]

Op donderdag 05 april 2001 10:54 schreef wasigh het volgende:
Dit doet alleen niets af aan het feit dat Php niet echt een OOP taal is..

I''ll second that!

Wel constructors aanmaken, geen deconstructors.. ehhh... Geen OOP dus .. althans nog niet.. wordt hard aangewerkt geloof ik.. tot dan gebruik ik fijn alleen includes waar mijn functies in staan

[Verwijderd]

Maar wel of je daar dan gebruik van moet maken.

-- Maar daar gaat deze thread niet over

da''s waar

[Verwijderd]

En dan hebben we het nog niet eens gehad over de snelheid. PHP is zelf geschreven in C (= niet object geörienteerd). Dus al die objecten worden geëmuleerd, hierdoor is de snelheid van programma''s die gebruik maken van objecten veel lager dan die ze niet gebruiken (in php). Dit kan een factor twee schelen (testje gedaan)

[dusty]

Op donderdag 05 april 2001 13:15 schreef Zef het volgende:
En dan hebben we het nog niet eens gehad over de snelheid.

Snelheid heeft verder niets te doen of PHP wel of niet OOP is.

[dusty]

Ik kan nog gemener zijn

Jouw theorie op C++ uitoefenen:

Assembler is niet OOP. C++ is in assembler gemaakt. Dus kan C++ nooit een goed OOP programma zijn.

Tussen C en C++ zit weinig verschil Kwa snelheid. Wat je in C kan maken kan je ook in C++ maken. Wat je in C++ kan maken kan je ook in C maken. De snelheid hangt meer af van de programmeur dan van de C++ of C.

In een lijstje van voordelen van C++ ten opzichte van C zal je ook niet "met C++ maak je code dat sneller is." zien staan.

[Verwijderd]

Ik voelde hem aankomen

/me merkt duidelijk dat Dusty vandaag goed wakker is

[Verwijderd]

Ik sluit me dan hierbij ook graag aan bij de vereniging ter bevordering van intelligente vragen

[dusty]

Op donderdag 05 april 2001 14:44 schreef Zef het volgende:
Ik sluit me dan hierbij ook graag aan bij de vereniging ter bevordering van intelligente vragen

U bent welkom om de tag in uw signature op te nemen.

[Verwijderd]

Tapadadaaaaa!

[brammetje]

ook nog iemand die hier een (intelligente) conclusie aan kan knopen??

Wel of niet?

[chem]

okay, laten we het er dan op houden dat OOP geen ZIN heeft in PHP maar wel HANDIG kan zijn om logisch gegroepeerde zaken bij elkaar te houden.

En voor die enkele keer dat je naar 2 databases wil connecten met 1 functie-set enofzo.

[Verwijderd]

PHP is geen OOP taal, OOP wordt wel gedeeltelijk ondersteund. OOP biedt over het algemeen vooral grote projecten voordelen, maar PHP heeft een aantal van die voordelen (en mogelijkheden) nog niet geimplementeerd.

edit:
Lezen is moeilijk

[sebas]

okaz, iedereem zit hier te discussieren wat wel en wat niet OOP is, heeft er iemand een goed stukje waar ik het na kan lezen zonder mensen als de bekende Java-nerds, Arien en rm-RF lastig te moeten vallen?

Graag ff posten...

Ik weet er zijn zat artikelen, maar uit deze discussie wordt voor mij op zijn zachtst gezegd meer onduidelijk dan duidelijk...

[dusty]

Op donderdag 05 april 2001 15:47 schreef Sebas het volgende:
okaz, iedereem zit hier te discussieren wat wel en wat niet OOP is, heeft er iemand een goed stukje waar ik het na kan lezen zonder mensen als de bekende Java-nerds, Arien en rm-RF lastig te moeten vallen?

Joepie.. Ik ben geen "java-nerd" Thanks!

Hier vindt je al je informatie die je nodig hebt.. (voorlopig althans..) zit ook goeie illustraties bij de uitleg.

[wasigh]

Op donderdag 05 april 2001 15:47 schreef Sebas het volgende:
okaz, iedereem zit hier te discussieren wat wel en wat niet OOP is, heeft er iemand een goed stukje waar ik het na kan lezen zonder mensen als de bekende Java-nerds, Arien en rm-RF lastig te moeten vallen?

En ik dan

Graag ff posten...

Ik weet er zijn zat artikelen, maar uit deze discussie wordt voor mij op zijn zachtst gezegd meer onduidelijk dan duidelijk...

Ik weet zo geen goed artikel. maar er bestaan genoeg boeken over.

Verder over de snelheid. Onafhankelijk of het geëmuleerd wordt of niet. Is (echt) oop trager. Omdat er veel overhead is. Met functie overriding en zo. Moet je in java bijvoorbeeld snelle code schrijven. Maak je variabelen en methoden dan final scheelt veel overhead.(tip van sun)

[mbravenboer]

Check dit maar eens:
(Niet Java afhankelijk)

http://java.sun.com/docs/books/tutorial/java/concepts/index.html

If you''ve never used an object-oriented language before, you need to understand the underlying concepts before you begin writing code. You need to understand what an object is, what a class is, how objects and classes are related, and how objects communicate by using messages. The first few sections of this trail describe the concepts behind object-oriented programming. The last section shows how these concepts translate into code.

What Is an Object?
What Is a Message?
What Is a Class?
What Is Inheritance?
What Is an Interface?
Questions and Exercises: Object-Oriented Concepts

Als je meer wilt weten over hoe OO in Java wordt gebruikt:
http://java.sun.com/docs/books/tutorial/java/index.html

Succes!

Edit: dusty was me voor

[mbravenboer]

Op donderdag 05 april 2001 15:56 schreef wasigh het volgende:

[..]
En ik dan

Val jij niet onder de Java-nerds dan?

[dusty]

Op donderdag 05 april 2001 16:00 schreef mbravenboer het volgende:
Edit: dusty was me voor

Hah!.. en ongeveer 5 minuten zelfs!

[wasigh]

(mijn) Conclusie
OOP is een mooie ontwikkeling. het bevordert nette code, en geeft de programmeur de mogelijkheid op een hoog abstract niveau te programmeren. Waardoor in het algemeen minder snel fouten gemaakt worden.

In Php laat de OOP implementatie te wensen over waardoor veel voordelen wegvallen. OOP programmeren is in PHP daarom eigenlijk niet op zijn plaats.

OOP programmeren betekent altijd meer overhead waardoor programma''s langzamer zullen draaiien. Aangezien dit om milliseconden gaat weegt dit meestal niet op tegen de voordelen van herbruikbaarheid, onderhoudbaarheid etc.

Verder is het aan de persoonlijke voorkeuren van de programmeur of en hoe hij/zij OOP gebruikt.

OOP maakt van een slechte programmeur geen goede programmeur, maar van een goede programmeur wel een betere.

Afsluiting: Gebruik OOP goed en je hebt er eigenlijk alleen profijt van.

[wasigh]

Op donderdag 05 april 2001 16:03 schreef mbravenboer het volgende:

[..]

Val jij niet onder de Java-nerds dan?

Blijkbaar niet

[Verwijderd]

Op donderdag 05 april 2001 16:08 schreef wasigh het volgende:
(mijn) Conclusie
OOP is een mooie ontwikkeling. het bevordert nette code, en geeft de programmeur de mogelijkheid op een hoog abstract niveau te programmeren. Waardoor in het algemeen minder snel fouten gemaakt worden.

In Php laat de OOP implementatie te wensen over waardoor veel voordelen wegvallen. OOP programmeren is in PHP daarom eigenlijk niet op zijn plaats.

OOP programmeren betekent altijd meer overhead waardoor programma''s langzamer zullen draaiien. Aangezien dit om milliseconden gaat weegt dit meestal niet op tegen de voordelen van herbruikbaarheid, onderhoudbaarheid etc.

Verder is het aan de persoonlijke voorkeuren van de programmeur of en hoe hij/zij OOP gebruikt.

OOP maakt van een slechte programmeur geen goede programmeur, maar van een goede programmeur wel een betere.

Afsluiting: Gebruik OOP goed en je hebt er eigenlijk alleen profijt van.

Met de nadruk op bijna

[Verwijderd]

Op donderdag 05 april 2001 16:08 schreef wasigh het volgende:
(mijn) Conclusie
[..]
Afsluiting: Gebruik OOP goed en je hebt er eigenlijk alleen profijt van.

Kijk daar hebben ''we'' wat aan, bedankt!!!

[dusty]

OOP maakt van een slechte programmeur geen goede programmeur, maar van een goede programmeur wel een betere.

Ik durf zelfs te beweren dat OOP van een slechte programmeur een NOG slechtere programmeur gemaakt wordt.

Iets met extra veel memory leaks enzo..

[wasigh]

Op donderdag 05 april 2001 16:14 schreef dusty het volgende:

Iets met extra veel memory leaks enzo..

Daar hebben er de Garbage Collector voor

[CyberSnooP]

Dan ben ik waarschijnlijk een slechte programmeur

Ik gebruik in PHP namelijk voor elke query een object (genaamt MySQLQuery). Voordeel daarvan is dat ik fouten kan afvangen binnen het object (dus ik dat niet voor elke MYSQL_QUERY() aanroep hoef te doen), dat ik geen result-nrs hoef te onthouden (das gewoon een variabele binnen het object geworden) en dat ik zelf heel kleine truukjes als getFirstValue() kan bouwen om het allemaal wat makkelijker te maken.

Maar wat ik nu hoor, is dat objecten je code ontzettend veel langzamer maken, dat het alleen maar ballast is, en dat je ook nog eens geheugen kunt leaken (hoe?!).

Nog iets: Destructors in PHP kunnen wel, als je je class extend vanaf de PEAR class. De functie $objectje->_objectje() wordt dan de destructor (die dan weer geen data kan uitvoeren, aangezien destructors ook worden uitgevoerd als de browser verbinding al verbroken is).

[wasigh]

Op donderdag 05 april 2001 16:26 schreef CyberSnooP het volgende:
Dan ben ik waarschijnlijk een slechte programmeur

Ik gebruik in PHP namelijk voor elke query een object (genaamt MySQLQuery). Voordeel daarvan is dat ik fouten kan afvangen binnen het object (dus ik dat niet voor elke MYSQL_QUERY() aanroep hoef te doen), dat ik geen result-nrs hoef te onthouden (das gewoon een variabele binnen het object geworden) en dat ik zelf heel kleine truukjes als getFirstValue() kan bouwen om het allemaal wat makkelijker te maken.

Kan heel makkelijk zijn. En als jij het wilt moet je het zeker zo blijven doen:)

Maar wat ik nu hoor, is dat objecten je code ontzettend veel langzamer maken, dat het alleen maar ballast is, en dat je ook nog eens geheugen kunt leaken (hoe?!).

Objecten maken je code langzamer, ik vind het in PHP meestal ballast. En geheugen leaken ging vooral over C++(volgens mij)

Nog iets: Destructors in PHP kunnen wel, als je je class extend vanaf de PEAR class. De functie $objectje->_objectje() wordt dan de destructor (die dan weer geen data kan uitvoeren, aangezien destructors ook worden uitgevoerd als de browser verbinding al verbroken is).

[SJR]

Op donderdag 05 april 2001 09:42 schreef dusty het volgende:

[..]

Ehh valt dan niet de eerste O van de afkorting af ? OP programmeren ?

En aangezien de P voor programming staat, valt die ook weg. O programmeren krijg je dan dus .

Maar ff on-topic:
Ik heb ook net bezig met PHP/MySQL en ik ben nu ook ervaring aan het opdoen in OOP in PHP. Volgens mij is dit vooral handig omdat je vele dingen maar 1 keer hoeft te ontwikkelen om het daarna vele keren te kunnen gebruiken.
Toegepaste voorbeelden van handig OOP gebruik zijn oa een Template class (zelf geschreven danwel XTemplates, FastTemplate, PHPLib, etc) en een database class.
Een template class is oa handig omdat je dan de HTML geheel gescheiden kan houden van de PHP. Als je dus de layout wil veranderen hoef je niet tussen de PHP door de HTML op te gaan zoeken. Dit kan ook handig zijn als de layout van de site gemaakt wordt door iemand anders als degene die de PHP voor z''n rekening neemt. De ontwerper hoeft dan immers niets te weten van PHP.
Ik moet wel zeggen dat ik templates nog best wel lastig vind om te begrijpen (ik ben nu beizg met PHPLib), het vereist wel weer een andere manier van programmeren.

Een database classe is handig als je wilt switchen van db. Stel je gebruikt eerst MySQL en gaat over Oracle. Zonder een db class zou je dan bijvoorbeeld in al je bestanden mysql_pconnect() moeten vervangen door OCILogon() oid. Als je een class gebruikt dan spreek al je functies gewoon aan met bijvoorbeeld $db->connect().

My 2 cents...

[edit]
Hmz... ik had alleen de eerste pagina van deze thread gelezen, misschien dat m''n reactie daarom niet helemaal op z''n plaats is.
Waarover ik nog wel zit te twijfelen is of ik voor een string een class ga schrijven of een verzameling functions. De functies doen dan oa: klaarmaken voor query (strippen van slashes en quotes ed), html verwijderen, code ([ b]) vervangen door html (< b>]), smilies toevoegen. Iemand nog suggesties voor meer functies en of dit in een class danwel een verzameling functies moet?

[tomato]

Een database classe is handig als je wilt switchen van db. Stel je gebruikt eerst MySQL en gaat over Oracle. Zonder een db class zou je dan bijvoorbeeld in al je bestanden mysql_pconnect() moeten vervangen door OCILogon() oid. Als je een class gebruikt dan spreek al je functies gewoon aan met bijvoorbeeld $db->connect().

Maar iedereen brengt het net of je dit soort handigheden alleen kunt gebruiken met een class. $db->connect zou imo net zo goed een ''normale'' functie kunnen zijn (ie db_connect()). Ik zeg niet dat je er geen class voor moet gebruiken, maar echte voordelen die je alleen (of makkelijker) met classes kunt bereiken heb ik nog niet horen noemen (veel van die voordelen heb je dan juist in PHP weer niet...). We gebruiken toch geen classes om interessant te doen he mensen?

* tomato gebruikt overigens af en toe wel classes in PHP maar vindt de argumenten hier een beetje slap

[ACM]

Op donderdag 05 april 2001 16:51 schreef tomato het volgende:
Maar iedereen brengt het net of je dit soort handigheden alleen kunt gebruiken met een class. $db->connect zou imo net zo goed een ''normale'' functie kunnen zijn (ie db_connect()).

Jahoor, helemaal mee eens. Maar dat neemt niet weg dat het op die manier van groeperen en verbergen van vars/connecties etc wel makkelijk is.
Maar klassen zijn nog steeds vooral prettig voor grote projecten. Zodra je met 10 man gaat programmeren is het m.i. makkelijker om allemaal een "interface" te implementeren. Dan allemaal in dezelfde file een functie te maken... (Ja kan idd ook in C en C++)

Ik zeg niet dat je er geen class voor moet gebruiken, maar echte voordelen die je alleen (of makkelijker) met classes kunt bereiken heb ik nog niet horen noemen (veel van die voordelen heb je dan juist in PHP weer niet...).

Ook daar heb je helemaal gelijk mee... De overerving is redelijk, maar niet perfect. Implementatie van Interfaces is er niet, en dat zou toch zeker prettig zijn (in java bv: serializable, comparable)
Maar voorzover ik weet, is men nog lang niet klaar met php, dus we maken nog kans om het mee te maken dat php echt OO ondersteund
Het doet het al een stuk beter dan (standaard) perl.

We gebruiken toch geen classes om interessant te doen he mensen?

Uiteraard wel...

Alhoewel ik ze gebruik om ergens op een centrale plek wat functies en "data" bij elkaar te houden die dan op een willekeurige plek (eventueel weer binnen een class of functie ) aangeroepen kunnen worden zonder dat je verder over speciale dingen hoeft na te denken.
Dit kan idd ook wel met functies, maar in veel gevallen moet je dan bijv. allerlei boolean''tjes en andere vars bovenaan je page (includen) zetten die je liever niet daar neer zet.

* ACM vindt het eigenlijk heel lastig uitleggen waarom ie oo in php gebruikt...

[Rense Klinkenberg]

Is er al iemand die echte meetgegevens heeft over het verschil OOP <-> !OOP in PHP?

Wanneer nl. blijkt dat OOP 2x langer duurt dan !OOP, lijkt het me dat je voor webapplicaties OOP geheel uit kan sluiten.

[wasigh]

[b]Op donderdag 05 april 2001 22:00

* ACM vindt het eigenlijk heel lastig uitleggen waarom ie oo in php gebruikt...

Je hoeft je niet te verdedigen hoor
als jij het fijn vind er vooral mee door gaan..

[ACM]

Op donderdag 05 april 2001 22:08 schreef wasigh het volgende:

[..]

Je hoeft je niet te verdedigen hoor
als jij het fijn vind er vooral mee door gaan..

Maakt het niet minder lastig om het uit te leggen.
In de meeste gevallen heeft "ik vindt het fijn" weer een of andere reden

[Verwijderd]

/me OOP zonder objecten is een interessant concept.

dusty: Ehh valt dan niet de eerste O van de afkorting af ? OP programmeren ?

Zag je die ?

[Verwijderd]

Sebas: Iedereem zit hier te discussieren wat wel en wat niet OOP is, heeft er iemand een goed stukje waar ik het na kan lezen zonder mensen als de bekende Java-nerds, Arien en rm-RF lastig te moeten vallen?

Hmm?

(Intelligente vragen vindt /me trouwens geen lastig vallen. Stomme vragen daarentegen...)

[dusty]

Op donderdag 05 april 2001 16:51 schreef tomato het volgende:
echte voordelen die je alleen (of makkelijker) met classes kunt bereiken heb ik nog niet horen noemen (veel van die voordelen heb je dan juist in PHP weer niet...). We gebruiken toch geen classes om interessant te doen he mensen?

* tomato gebruikt overigens af en toe wel classes in PHP maar vindt de argumenten hier een beetje slap

Ik heb het al een keer genoemd. (ergens op de eerste pagina.) Data encapsulation.

Bovendien is het vaak niet eens nodig om OO te programmeren met PHP. ( als webapplicatie dat is..) Vaak kan het ook gewoon met functies die je ook kan hergebruiken. In PHP is daar eigenlijk weinig verschil in.

Ik vrees dat de meeste mensen het juist wel doen om interresant te doen. Ik heb zelden dat een php file van mij langer loopt als een paar seconden. (heb wel wat php files die opkunnen lopen naar 8 uur ofzo.. maar dat zijn geen webapplicaties... )

Persoonlijk vindt ik ook dat er weinig argumenten worden aangedragen waarom men hier OO gebruikt in PHP.

[dusty]

Op vrijdag 06 april 2001 09:02 schreef Arien het volgende:
Zag je die ?

Zoals mensen banner blind zijn.. ben ik smiley blind aan het worden

Ik vindt de afkorting OP op zich wel leuk

[brammetje]

fok, scheelt best wel veel..

[tomato]

Wat, wat

Kan wel een paar mogelijkheden bedenken, maar ben zeer benieuwd

[mbravenboer]

Op vrijdag 06 april 2001 09:29 schreef dusty het volgende:
Ik heb het al een keer genoemd. (ergens op de eerste pagina.) Data encapsulation.

Op zich is dat natuurlijk een hele interessante term, maar ik denk dat de voordelen er toch vooral in liggen dat OO gewoon makkelijker programmeert (als je het eenmaal goed beheerst). OO ligt heel dicht bij de echte wereld (welke wereld is echt ), waardoor je je code inzichtelijk kan houden. Praten over objecten die samenwerken en elkaar gebruiken is gewoon makkelijk.

Ik vrees dat de meeste mensen het juist wel doen om interresant te doen.

Dat vind ik te kort door de bocht. Stel je als programmeur werkt met C++, C#, Java of Smalltalk en een uitgebreide ervaring met OO hebt, dan programmeert OO gewoon makkelijker (zelfs in PHP ). OO is een manier van leven , een verslaving . Ik denk dat ik er op dit moment vrij slecht uit zou komen als ik een procedureel programma goed op moet zetten.

Ik heb zelden dat een php file van mij langer loopt als een paar seconden. (heb wel wat php files die opkunnen lopen naar 8 uur ofzo.. maar dat zijn geen webapplicaties... )

Wat heeft looptijd met het al of niet gebruiken van OO te maken?

[dusty]

mbravenboer Op zich is dat natuurlijk een hele interessante term, maar ik denk dat de voordelen er toch vooral in liggen dat OO gewoon makkelijker programmeert (als je het eenmaal goed beheerst). OO ligt heel dicht bij de echte wereld (welke wereld is echt ), waardoor je je code inzichtelijk kan houden. Praten over objecten die samenwerken en elkaar gebruiken is gewoon makkelijk.

OO is meer een denkwijze. Je kunt namelijk een OO ontwerp ook nog steeds zonder een OO programmeertaal implementeren

mbravenboer Dat vind ik te kort door de bocht. Stel je als programmeur werkt met C++, C#, Java of Smalltalk en een uitgebreide ervaring met OO hebt, dan programmeert OO gewoon makkelijker (zelfs in PHP ). OO is een manier van leven , een verslaving . Ik denk dat ik er op dit moment vrij slecht uit zou komen als ik een procedureel programma goed op moet zetten.
Dan zou jij moeten weten dat veel tekortkomingen in php zitten. (waar overigens wel hard aan gewerkt wordt.. dus heb wel vertrouwen dat het goed komt met php & oop )

mbravenboer Wat heeft looptijd met het al of niet gebruiken van OO te maken?
Blijkbaar meer dan dat jij denkt. OOP kost gewoon overhead. Met een webapplicatie wil je dat de resultaten zo snelmogelijk naar de gebruiker gegooid wordt en dan maakt het wel degelijk uit, De overhead creeert een groot verschil.
Met een programma dat een "langere" tijd draait is dat relatief onbelangrijker dan een "programma" dat maar 3 seconden draait.

[mbravenboer]

Op vrijdag 06 april 2001 12:44 schreef dusty het volgende:
Blijkbaar meer dan dat jij denkt.

Sorry ik moet toch even kwijt dat je er verstandiger aan doet niet zo te reageren als je absoluut niet weet tegen wie je het hebt. Ik heb ondertussen geleerd dat je nooit, maar dan ook nooit, spottend of ironisch (zonder een smile) tegen onbekende mensen moet praten over heb web. Dit kan soms heel erg belachelijk overkomen.

OOP kost gewoon overhead. Met een webapplicatie wil je dat de resultaten zo snelmogelijk naar de gebruiker gegooid wordt en dan maakt het wel degelijk uit, De overhead creeert een groot verschil.
Met een programma dat een "langere" tijd draait is dat relatief onbelangrijker dan een "programma" dat maar 3 seconden draait.

Jij noemde het probleem van de looptijd van OO programma''s in een adem met de opmerking dat mensen die in PHP op een OO wijze programmeren dit vaak doen om interessant te zijn. Daarom beschouwde ik jouw situatie als een illustratie dat je geen OO moet gebruiken in PHP. Je zei echter ook dat de looptijd van al jouw PHP proggies slechts zeer klein is. Daarom snapte ik het argument tegen OO niet. Als jouw programma niet zo intensief is en dus maar enkele seconden draait, is het zeker niet relevant als het een halve seconde langer draait.

Mijn vraag was dus bedoeld om jouw opmerking duidelijker te krijgen. Uiteraard is OO intensiever, maar naast looptijd is ook nog zoiets als ontwikkeltijd, en die ligt in dit geval toch sterk in het voordeel van OO.
Vandaar dat ik in jouw situatie van kleine programma''s met kleine draaitijd, dit argument niet op zijn plaats vond.

Overigens is het probleem van de overhead van OO software _naar mijn mening_ met de huidige stand van de technologie absoluut niet relevant.

Edit: kleine toevoeging en leren tikken

[dusty]

mbravenboer Sorry ik moet toch even kwijt dat je er verstandiger aan doet niet zo te reageren als je absoluut niet weet tegen wie je het hebt. Ik heb ondertussen geleerd dat je nooit, maar dan ook nooit, spottend of ironisch (zonder een smile) tegen onbekende mensen moet praten over heb web. Dit kan soms heel erg belachelijk overkomen.
Agreed, was gewoon de vergeten, sorry.

mbravenboer Jij noemde het probleem van de looptijd van OO programma''s in een adem met de opmerking dat mensen die in PHP op een OO wijze programmeren dit vaak doen om interessant te zijn. Daarom beschouwde ik jouw situatie als een illustratie dat je geen OO moet gebruiken in PHP. Je zei echter ook dat de looptijd van al jouw PHP proggies slechts zeer klein is. Daarom snapte ik het argument tegen OO niet. Als jouw programma niet zo intensief is en dus maar enkele seconden draait, is het zeker niet relevant als het een halve seconde langer draait.

Overigens is het probleem van de overhead van OO software _naar mijn mening_ met de huidige stand van de technogolgie absoluut niet relevant.

"Een halve seconde maakt toch niet uit." ?
Als het nu te traag is komt er toch wel een nieuwere machine die sneller is of je moet het upgraden.

Hallo Microsoft ?

Dat je dit zegt, zegt meer over jou als programmeur zijnde dan over iets anders. Als je genoeg hits krijgt begint opeens die 1/2 seconde per hit wel uit te maken.

Neem tweakers. 500.000 hits per dag. * 0.5 seconden = iets over de 69 uur per dag.

Yep bij nader inzien je hebt compleet gelijk die halve seconden maakt niets uit

[Verwijderd]

dusty: Yep bij nader inzien je hebt compleet gelijk die halve seconden maakt niets uit

Als die halve seconde uitmaakt dan zijn er behalve OOP nog wel een paar dingen te noemen die je qua software zou kunnen aanpassen, waarvan PHP er een is.

En behalve snelheid is er ook nog onderhoudbaarheid, implementatietijd, kosten etc. Het hangt er maar vanaf waar het om gaat.

[mbravenboer]

Op vrijdag 06 april 2001 14:47 schreef dusty het volgende:
Agreed, was gewoon de vergeten, sorry.

Ok, never mind .

"Een halve seconde maakt toch niet uit." ?
Als het nu te traag is komt er toch wel een nieuwere machine die sneller is of je moet het upgraden.

Dat je dit zegt, zegt meer over jou als programmeur zijnde dan over iets anders.

Val me nooit aan op m''n programmeerkwaliteiten... Ik ben gevoelig op dat soort punten .

De halve seconde was slechts een voorbeeld... dat had ik beter niet kunnen doen . Uiteraard gaat het niet om een absolute waarde maar over een percentage van overhead. In dit geval zou de overhead dus ongeveer 1/6 zijn, wat dus inderdaad te veel is. Gelukkig is dit ook niet het geval in de meeste OO talen.

Als je genoeg hits krijgt begint opeens die 1/2 seconde per hit wel uit te maken.

Neem tweakers. 500.000 hits per dag. * 0.5 seconden = iets over de 69 uur per dag.

:? 500.000 * 3 seconden is ... hum nog meer. Wat is dan 69 uur op een dag ? >:)Omdat mijn voorbeeld niet correct was, sleur ik jou mee in mijn fout .

Yep bij nader inzien je hebt compleet gelijk die halve seconden maakt niets uit

Hum, weet helaas geen exacte percentages te noemen voor enkele voorbeeldtalen. Ik denk dat de gemiddelde overhead onder de 10 procent ligt. Wellicht dat het interessant is om eens wat metingen te doen in PHP. Jouw voorbeeld geeft IMHO een beetje een verkeerd beeld .

[dusty]

dusty: Yep bij nader inzien je hebt compleet gelijk die halve seconden maakt niets uit
Arien Als die halve seconde uitmaakt dan zijn er behalve OOP nog wel een paar dingen te noemen die je qua software zou kunnen aanpassen, waarvan PHP er een is.

En behalve snelheid is er ook nog onderhoudbaarheid, implementatietijd, kosten etc. Het hangt er maar vanaf waar het om gaat.

Klopt. Maar de code kan ook zonder OOP nog steeds redelijk overzichtelijk en onderhoudbaar zijn.

Implementatietijd maakt weinig uit tussen OOP en niet OOP.

Vooral bij PHP maakt die 1/2 seconden al uit

Daartegen over staat natuurlijk dat de gemiddelde sql query die hier voorbijkomt het al ontzettend vertraagd

[Tomatrix]

OO is meer een denkwijze. Je kunt namelijk een OO ontwerp ook nog steeds zonder een OO programmeertaal implementeren

Ja? Hoe implementeer je dan dingen als bijvoorbeeld polymorphisme of interfaces?
Misschien kom je met pointers naar functies een endje op weg maar red je het volgens mij niet.

[dusty]

Op vrijdag 06 april 2001 14:56 schreef mbravenboer het volgende:
Val me nooit aan op m''n programmeerkwaliteiten... Ik ben gevoelig op dat soort punten .

Sorry

Op vrijdag 06 april 2001 14:56 schreef mbravenboer het volgende:
De halve seconde was slechts een voorbeeld... dat had ik beter niet kunnen doen . Uiteraard gaat het niet om een absolute waarde maar over een percentage van overhead. In dit geval zou de overhead dus ongeveer 1/6 zijn, wat dus inderdaad te veel is. Gelukkig is dit ook niet het geval in de meeste OO talen.

Maar helaas (nog) te vaak bij PHP.

Op vrijdag 06 april 2001 14:56 schreef mbravenboer het volgende:
:? 500.000 * 3 seconden is ... hum nog meer. Wat is dan 69 uur op een dag ? >:)Omdat mijn voorbeeld niet correct was, sleur ik jou mee in mijn fout .

Een stuk minder dan 500.000 * 3.5 seconden

Op vrijdag 06 april 2001 14:56 schreef mbravenboer het volgende:
Hum, weet helaas geen exacte percentages te noemen voor enkele voorbeeldtalen. Ik denk dat de gemiddelde overhead onder de 10 procent ligt. Wellicht dat het interessant is om eens wat metingen te doen in PHP. Jouw voorbeeld geeft IMHO een beetje een verkeerd beeld .

Klopt.. omdat ik specifiek doel op PHP op het moment.

Als je naar C++ gaat kijken ligt bij een algemeen project de overhead toch ruim onder de 5%. De objecten bij een gemiddeld C++ blijft ook langer bestaan dan maar een paar seconden.

Omdat je bij php toch vaak tegen een "klein" programma praat. (want in principe moet je elke php file zien als een aparte applicatie) is de overzicht nog wel te behouden.

Bij een C++ programma wordt die code al stukken langer. En dan komt opeens de voordelen van OOP aan het licht.
Makkelijker te onderhouden.
Overzichtelijk etc etc.

Ontknoping: OOP is een pracht van een oplossing. Maar het moet wel op de juiste plaatsen worden toegepast. Als je opeens meer overhead genereert dan noodzakelijk is wordt het opeens NIET interessant om OOP te gebruiken. Ik ben al heel veel mensen tegen gekomen die zweren alleen bij OOP. die doen niets anders. Ik ken ook mensen die zweren bij alleen Niet OO programmeren. Beide types sluiten hun ogen voor de waarheid. Wat de beste oplossing is hangt af van het "probleem" of in dit geval wat er gemaakt moet worden. Betekent echter dat bij PHP op het moment zelden OOP gebruikt HOEFT te worden.

[mbravenboer]

Op vrijdag 06 april 2001 15:00 schreef dusty het volgende:
Implementatietijd maakt weinig uit tussen OOP en niet OOP.

Hum, daar ben ik het zeer sterk mee on eens, maar dat zal je al wel begrepen hebben .
Ik kan wel weer een heel zwamverhaal over hergebruik, onderhoudbaarheid etc op gaan hangen maar laat ik dat maar niet meer doen...

Vooral bij PHP maakt die 1/2 seconden al uit

Zucht... was een fout voorbeeld...
Als je volgens jou trouwens een OO denkwijze in een niet OO taal kan implementeren... dan kan je ook een OO taal naar een niet OO taal compileren. Conclusie is dus dat of: jouw stelling klopte niet (een OO design kan niet een procedurele taal worden geimplementeerd) of: OO heeft geen overhead.

Overigens is het wellicht boeiend om te weten dat vrijwel alle software ongeveer 90 procent van de tijd in 10 procent van de code doorbrengt. Mijn voorstel is dan ook altijd om onderhoudbaarheid, ontwikkeltijd en duidelijkheid in deze 90 procent voorop te stellen en alleen in de resterende 10% aandacht te besteden aan optimalisering.

Door de lagere ontwikkeltijd van OO houdt je dus meer tijd over voor de echte kern van je snelheidsprobleem, waardoor je betere optimalisatie kan toepassen, waardoor een OO programma dus sneller kan zijn dan een procedureel programma .

[mbravenboer]

Op vrijdag 06 april 2001 15:10 schreef dusty het volgende:
Een stuk minder dan 500.000 * 3.5 seconden

Grrr..

Ontknoping: ...

Hier kan ik me wel bij aansluiten... Vergeet trouwens niet FP in het rijtje van mogelijke oplossingen .

[ACM]

Op vrijdag 06 april 2001 18:11 schreef freak007 het volgende:
Is er al iemand die echte meetgegevens heeft over het verschil OOP <-> !OOP in PHP?

Wanneer nl. blijkt dat OOP 2x langer duurt dan !OOP, lijkt het me dat je voor webapplicaties OOP geheel uit kan sluiten.

Geef mij 2 scripts die identiek iets doen...
De ene met objecten, de andere met losse functies...
Dan laat ik ab (apachebench) er wel (@vulcanus.its...) op los

Mail/icq me maar met een paar scripts... Mysql/postgresql gebruik is ook niet echt een probleem...

[Verwijderd]

Ja, dat heb ik dus gedaan Ik heb dit script gebruikt (zeg maar als het niet helemaal eerlijk is wat ik doe):

PHP:

<?
php

function gt() {

    $mtime = microtime();

    $mtime = explode( '' '' , $mtime );

    $mtime = $mtime[ 1 ] + $mtime[ 0 ] ;

    return abs($mtime);

}

class Reken {

    var $i=0;

    

    function plusEen() {

        $this->i = $this->i + 1;

    }

}

$i = 0;



function plusEen($v) {

    return $v+1;

}



$start = gt();

for($c=0;$c<10000;++$c)

    $i = plusEen($i);

echo gt() - $start. "<br>";



$start = gt();

$r = new Reken();

for($c=0;$c<10000;++$c)

    $r->plusEen();

echo gt() - $start. "<br>";
?>

De eerste waarde geeft de tijd zonder objecten, de tweede met.

[ACM]

Op vrijdag 06 april 2001 19:57 schreef Zef het volgende:
Ja, dat heb ik dus gedaan Ik heb dit script gebruikt (zeg maar als het niet helemaal eerlijk is wat ik doe):

PHP:

<?
scripje
?>

De eerste waarde geeft de tijd zonder objecten, de tweede met.

Ik haal het wel uitelkaar... En bench ze afzonderlijk...
Maar voor een script van 5 regels, is niet echt eerlijk natuurlijk

Maar goed:

code:

Server Software:        Apache/1.3.19
Server Hostname:        vulcanus.its
Server Port:            80

Document Path:          /acm/func.php
Document Length:        21 bytes

Concurrency Level:      1
Time taken for tests:   8.555 seconds
Complete requests:      100
Failed requests:        11
   (Connect: 0, Length: 11, Exceptions: 0)
Total transferred:      21988 bytes
HTML transferred:       2088 bytes
Requests per second:    11.69
Transfer rate:          2.57 kb/s received

Connnection Times (ms)
              min   avg   max
Connect:        0     0     2
Processing:    80    84    91
Total:         80    84    93

code:

Server Software:        Apache/1.3.19
Server Hostname:        vulcanus.its
Server Port:            80

Document Path:          /acm/class.php
Document Length:        20 bytes

Concurrency Level:      1
Time taken for tests:   14.141 seconds
Complete requests:      100
Failed requests:        13
   (Connect: 0, Length: 13, Exceptions: 0)
Total transferred:      21887 bytes
HTML transferred:       1987 bytes
Requests per second:    7.07
Transfer rate:          1.55 kb/s received

Connnection Times (ms)
              min   avg   max
Connect:        0     0     1
Processing:   133   140   155
Total:        133   140   156

[Verwijderd]

Daarom heb ik ook mijn complete forum helemaal object vrij gemaakt, en het blaast behoorlijk

[sebas]

Arien:
Intelligente vragen vindt * Arien trouwens geen lastig vallen. Stomme vragen daarentegen...)

* sebas vind vragen niet erg intelligent als het om algemene dingen gaat die wel ergens goed gedocumenteerd staan.

Ik lees liever eerst en als er dan nog onduidelijkheden zijn vraag ik het. En ik stoor me soms ook aan mensen die te lui zijn om te lezen en zich liever dingen voor laten kouwen.

[Verwijderd]

Sebas: * sebas vindt vragen niet erg intelligent als het om algemene dingen gaat die wel ergens goed gedocumenteerd staan.

Dat bedoel ik met stomme vragen. Dat is de weg vragen als je naast een plattegrond staat.

[wasigh]

Op vrijdag 06 april 2001 23:49 schreef Arien het volgende:
Sebas: * sebas vindt vragen niet erg intelligent als het om algemene dingen gaat die wel ergens goed gedocumenteerd staan.

Dat bedoel ik met stomme vragen. Dat is de weg vragen als je naast een plattegrond staat.

Dat vind ik een mooie afsluiting...

Dus zijn we het er eindelijk overeens dat OOP in php over het algemeen vooral overhead betekent.:)

Maar dit er netuurlijk gevallen zijn waar het wel nuttig is.

[dusty]

Op zondag 08 april 2001 13:10 schreef wasigh het volgende:
Dus zijn we het er eindelijk overeens dat OOP in php over het algemeen vooral overhead betekent.:)

Maar dit er netuurlijk gevallen zijn waar het wel nuttig is.

Ben ik het compleet mee eens.

Er zijn heel veel gevallen waar OOP nuttig is. Voor het ontwerpen van je webapplicatie kan je nog steeds de OOP ontwerp gebruiken. Je zult alleen functies moeten gebruiken i.p.v. de specifieke methoden die OOP biedt. (maar in 99% van het geval is dat wel te doen )

[Tuinhark]

Ben op dit moment bezig met een secret little [PHP] projectje (nee, niet YapBB ) waarbij het gebruik van classen en zelfs overerving bijzonder nuttig blijkt. Ten opzichte van het ''oude design'', is het een enorme vooruitgang en werkt het geheel tot wel 5 keer sneller.

Uiteraard is dat een bijverschijnsel van het ontwerp als geheel; dit effect komt niet omdat ik nu ineens de magische classes toepas. Maar, het nieuwe ontwerp maakt het er wel een stuk simpeler op om functionaliteit te scheiden en data tijdens de request te bewaren. (lees hier aan het einde een goed stukje)

Wanneer dit dingetje af is (at present zo''n beetje 95% ), zal ik het nog ff melden. (Denk dat met name tomato wel geïnteresseerd zal zijn. ) ''k Vermoed dat het wel interessant studiemateriaal kan zijn voor de wat meer geavanceerde PHP programmeur..

[dusty]

We wachten even af