[PHP4/5] basisfunctionaliteit van classes

[BikkelZ]

In Java heb je voor classes bijvoorbeeld toString(), dat is een functie die iedere class sowieso heeft. Zeg maar het prototype van alles classes.

Nou wil ik eigenlijk in iedere class die ik in PHP gebruik dezelfde rudimentaire error functionaliteit hebben, waarmee ik de meest simpele objecten nog een redelijk uitgebreide set aan errorfuncties kan meegeven zonder lappen code door ieder class te gaan verspreiden.

Doe ik dat dan het beste door bijvoorbeeld iets te doen als:

PHP:

Class Prototype
{
// fart
}

Class DoetWatLeuks extends Prototype
{
// poo
}

Of zijn daar wat subtielere mechanismes voor?

[Snake]

Dat is geen prototype voor iedere klasse.

De toString() methode is een methode voor de Object klasse. En iedere klasse is daarna afgeleid van de Object klasse.

Dus jij zal jouw superklasse moeten schrijven, maar daarin je basisfunctionaliteit, die je overal nodig hebt, en daarna extends je subklassen met die superklasse.

Of je maakt gewoon ergens een aparte functie.

[BikkelZ]

Ik heb in Java nog nooit 'extends Object' geschreven. Daarmee is de klasse Object het prototype voor alle andere klassen buiten de primitieven, toch?

En ik kan wel een aparte functie schrijven, maar ik wil weten of dat er een fout is opgetreden in die klasse voordat ik verder ga met iets bijvoorbeeld. Je hoeft je Query niet uit te voeren als je Connection al mislukt is om welke reden dan ook, nietwaar.

[ Voor 46% gewijzigd door BikkelZ op 07-06-2007 16:46 ]

[whoami]

BikkelZ schreef op donderdag 07 juni 2007 @ 16:44:
Ik heb in Java nog nooit 'extends Object' geschreven. Daarmee is de klasse Object het prototype voor alle andere klassen buiten de primitieven, toch?

Da's omdat die overerving impliciet gebeurd door de Java Runtime als ik het goed heb.
Da's in .NET ook zo. Ook daar heb je een class 'object' die de parent class is van iedere andere class die je maakt.
Bekijk die object-class maar eens in Java, en je zal zien dat die toString method daarin geimplementeerd is. Ga dan ook eens kijken naar een willekeurige andere Java Class, en je zal daar zien dat die toString method overriden is.

[Creepy]

Je zult toch echt een eigen class moeten schrijven met die error handling en alle andere classes daarvan laten overeven. Desnoods kan je er een interface van maken maar dan zal elke class die interface zelf moeten implementeren.

[Gwaihir]

Je hebt 't over klassen en roept nonchalant "PHP4/5"? Daar verschillen PHP4 en 5 nogal (lees: PHP4 mist VEEL). Weet je zeker dat je PHP4 compatibiliteit nodig hebt?

__toString is in PHP5 bijvoorbeeld een magic method.

[BikkelZ]

Ja ik ben misschien inderdaad een beetje nonchalant in mijn vraagstelling, maar het is op zich wel een reele kwestie. Je komt op een bepaald moment een beetje op het punt uit dat je bepaalde dingen eigenlijk in bijna iedere instantie van een klasse wil hebben, zoals errorhandling, userrechten, etc. zelfs al is het maar indirect.

Kijk, als je naar JavaScript kijkt, dat is net Silly Putty, als je wil dan kun je er bijna alles van maken door de prototypes te gaan overschrijven. Dat gaat echt heel erg ver. PHP is uit C voort gekomen en is eigenlijk behoorlijk statisch daarbij of zelfs bij Java vergeleken.

Ik was benieuwd hoe jullie dat soort vraagstukken oplossen. De 'extends' optie is degene waarvoor ik zou moeten gaan als ik het tot nu toe goed op een rijtje heb gezet.

[user109731]

BikkelZ schreef op donderdag 07 juni 2007 @ 21:48:
Ja ik ben misschien inderdaad een beetje nonchalant in mijn vraagstelling, maar het is op zich wel een reele kwestie. Je komt op een bepaald moment een beetje op het punt uit dat je bepaalde dingen eigenlijk in bijna iedere instantie van een klasse wil hebben, zoals errorhandling, userrechten, etc. zelfs al is het maar indirect.

Zoiets wil je imho juist niet in elke class, maar in aparte classes: ErrorLogger, User, ...

[ Voor 24% gewijzigd door user109731 op 07-06-2007 21:59 ]

[Verwijderd]

Idd vergeet niet dat PHP alles per hit compiled, je wilt dus je classes so lean and mean als mogelijk houden. Althans ik wel. Include only what you need, ipv include everything you might need

[_Hades_]

Ik weet niet zeker of ik precies begrijp waar jullie het over hebben, ik ben wat betreft OO in php ook nog een redelijke beginner.

Eerder als ik bijvoorbeeld een class voor mijn db afhandeling had, ging ik iedere volgende class die ik aanmaakte, en die gebruik maakte van de db aanmaken als "class bla extends db" (dit is toch wat de ts bedoeld of niet?).

Ik ben met dit soort praktijken gestopt, omdat die classes die ik schreef verder niets met db functies te maken hebben (je extend imho een class omdat je functionaliteit wil toevoegen aan die class, en niet omdat je een of andere vage class hebt die toevallig een db functie gebruikt).

Wat ik nu doe is gewoon de classes die gebruikt worden in een bepaalde class includen bovenaan de pagina, en vervolgens aanroepen tijdens de __construct oid (of wanneer je ze ook maar nodig hebt) en in een variabele binnen het object gooien.

Volgens mij maak je op die manier de meest begrijpbare code en loop je op gegeven moment ook niet vast als je bijv functies uit meerdere classes nodig hebt

[BikkelZ]

Verwijderd schreef op donderdag 07 juni 2007 @ 22:54:
Idd vergeet niet dat PHP alles per hit compiled, je wilt dus je classes so lean and mean als mogelijk houden. Althans ik wel. Include only what you need, ipv include everything you might need

Ja lekker volgens het Java principe gaan OO'en dat moet je dus echt niet doen - het gaat echt heel specifiek over hele generieke dingen als errors of security, dingen die je in 80% van je classes wel tegen komt.

JanDM schreef op donderdag 07 juni 2007 @ 21:55:
[...]

Zoiets wil je imho juist niet in elke class, maar in aparte classes: ErrorLogger, User, ...

Hoe doe je dat dan als je zowel een Error als een User wil implementeren in een klasse? En aan de andere kant, als je minstens een keer per page (want PHP is wel een beetje de goudvis onder de programmeertalen) wel User of Error gebruikt, wat is dan de performance hit als je die als 'Prototype' class gebruikt waarvanuit je iedere class extendt?

[Verwijderd]

Ik heb een aantal classes specifiek voor dat soort dingen gemaakt, ik heb een render class (smarty extended) DBlayer en een generieke debug/error afhandeling. Die error afhandeling heb ik bewust niet in een class gedaan maar gewoon een simpele functie die wat toevoegt aan de errorlog en die error log is gewoon een variabele in het geheugen.

Zelf vind ik het een beetje nutteloos om een class te maken puur om een class te maken. Ik vind dat je een keuze moet maken of je bepaalde functionaliteit later nog wil extenden of dat het gewoon support functies zijn voor je framework. Een DB engine wil je later wel eens extenden, al was het alleen maar om een generieke interface voor verschillende DB layers te maken. Zelfde geldt voor je render layer. Maar een debugging layer blijft voor mij niet veel meer als gewoon boodschappen toevoegen aan je debug output en ik kan ook niet bedenken waarom ik dat ooit zou willen extenden naar meer dan een boodschap in mijn error log variabele.


Mijn hele debug process bestaat uit de volgende code, niet veel soeps maar doet voor mij precies wat ik wil weten

PHP:

  function getMicroT()
  {
    list($usec, $sec) = explode(" ",microtime());
    return ((float)$usec + (float)$sec);
  }

  function timeElapsed($reset = false)
  {
    static $timeOffset="";
    if ($timeOffset=="" || $reset)
    {
      $timeOffset = getMicroT();
      return "@".strftime("%H:%M:%S")."h";
    }
    else
    {
      return "+".sprintf("%02.05f",getMicroT()-$timeOffset)."s";
    }

  }

  /**
   * Function addDebug
   *
   * Adds the debug txt to the debug log
   * @param txt the text to send to the log
   * @param bool error. TRUE = Print red ERROR
   */
function addDebug($txt,$error=FALSE)
{
  global $global_debugText;
  if (getConfig("debug") >0)
  {
      #if($viewhtml) 
        #   $txt = htmlentities($txt);
      if (is_array($txt) || is_object($txt))
          {
           $txt = "<pre>".var_export($txt, true)."</pre>";
          }
      $string = "[".timeElapsed();
      if  (function_exists("memory_get_usage")) $string .= "<small> (".sprintf("%02.02f", (memory_get_usage()/1024))." Kb used)</small> ";
      $string .="]";
      if ($error)
        $global_debugText[]= "<span style='color:red;font-weight:bold;'>".$string.$txt."</span>";
      else
        $global_debugText[]= $string.$txt;
    }
}

Waarom zou ik dat in een class doen?? Alleen omdat ik dan 1 global uit spaar??

[Janoz]

Ik denk dat je je eens eventjes ietsje meer in OO moet gaan verdiepen. De dingen die je hier loopt te roepen slaan imho helemaal nergens op. Hetgeen jij 'volgens java principes gaan OO-en' noemt is eigenlijk JUIST de manier hoe je met OO zou moeten werken. Dat je in 80% van de classes een user nodig hebt betekent nog niet dat het een user is.

Hoe doe je dat dan als je zowel een Error als een User wil implementeren in een klasse?

Een class is niet een user, maar heeft eventueel een user. De class heeft dus gewoon als property een userclass. Hetzelfde geld voor een error handler. Deze krijg je in je class, hetzij via een singleton pattern, hetzij door het gewoon mee te geven.

De manier zoals jij het probeert op te lossen is nodeloos ingewikkeld. Onderdeel van OO programmeren is juist dat je probeert verantwoordelijkheden zoveel mogelijk af te bakenen. Wat jij nu doet is zo ongeveer alles van alles afhankelijk maken.

[Michali]

BikkelZ schreef op donderdag 07 juni 2007 @ 23:57:
[...]


Ja lekker volgens het Java principe gaan OO'en dat moet je dus echt niet doen - het gaat echt heel specifiek over hele generieke dingen als errors of security, dingen die je in 80% van je classes wel tegen komt.

Waarom niet? Het is overigens niet een Java principe, maar gewoon een algemeen OO principe waar je volgens moet werken. Dat PHP iedere hit compiled is onzin. Gewoon een optimizer installeren, dan gebeurt dat niet meer. Dat hele nadeel bestaat dan niet meer.

[Janoz]

Verwijderd schreef op vrijdag 08 juni 2007 @ 09:03:
Waarom zou ik dat in een class doen?? Alleen omdat ik dan 1 global uit spaar??

Het hoeft ook niet perse . Een class maken om het class maken is inderdaad niet een juiste reden. Wat echter wel handig is wanneer je er een class van maakt is dat je in je debugger ook wat config bij kunt houden. Die config blijft dan binnen de die class dus heeft geen invloed op de rest van je applicatie, en je kunt bijvoorbeeld in de constructor van je object aangeven waar die config vandaan gehaald moet worden. Op je ontwikkel omgeving difinieer je vervolgens dat alles lekker op het scherm komt, terwijl je op productie aangeeft dat alleen fatal messages in een log terecht moeten komen. De hele rest van je applicatie heeft geen enkele last van deze uitbreiding.

[BikkelZ]

Michali schreef op vrijdag 08 juni 2007 @ 09:13:
[...]

Waarom niet? Het is overigens niet een Java principe, maar gewoon een algemeen OO principe waar je volgens moet werken. Dat PHP iedere hit compiled is onzin. Gewoon een optimizer installeren, dan gebeurt dat niet meer. Dat hele nadeel bestaat dan niet meer.

Nou als ik in Java iets schrijf dan werk ik meestal netjes per klasse in een losse file, of soms als het heel nauw samenhangt in een file. Ga je dat in PHP doen, dan moet je veel te veel losse includes doen. Ga je al die includes samenvoegen in een grote file, heb je daar weer een performance hit op op het moment dat je maar een klein beetje van die functionaliteit nodig hebt. Ik moet wel heel eerlijk zeggen dat ik nog niet met optimizers er op gedoken ben, maar dat was waar ik en andere mensen met mij wel tegen aan lopen of gelopen zijn.

Java dat wordt gecompileerd en daardoor al geoptimaliseerd van te voren waardoor je dat soort problemen helemaal niet hebt. Bovendien blijft de gemiddelde Java thread toch echt langer in leven dan de gemiddelde PHP thread, waardoor het veel logischer wordt dat al je classes een keer aan bod komen.

Janoz schreef op vrijdag 08 juni 2007 @ 09:13:
Ik denk dat je je eens eventjes ietsje meer in OO moet gaan verdiepen. De dingen die je hier loopt te roepen slaan imho helemaal nergens op. Hetgeen jij 'volgens java principes gaan OO-en' noemt is eigenlijk JUIST de manier hoe je met OO zou moeten werken. Dat je in 80% van de classes een user nodig hebt betekent nog niet dat het een user is.

Er lopen hier een aantal zaken door elkaar, namelijk de efficiency en het nut van heel strikt OO gaan toepassen zoals je dat in Java doet, en de kneedbaarheid van JavaScript wat betreft prototypes van bijvoorbeeld Object, Array of Element. Ik denk dat je je er wel in verdiept hebt, en ik neem aan dat je het met me eens bent dat het een erg vernuftige (en misschien zelfs verfrissende) manier van werken is.

De vraag is simpelweg: kan ik aan het prototype van Object in PHP4 danwel 5 morrelen of moet ik als ik dat wil bereiken toch gewoon gaan extenden waar dat nodig is?

[ Voor 35% gewijzigd door BikkelZ op 08-06-2007 10:42 ]

[SchizoDuckie]

BikkelZ schreef op vrijdag 08 juni 2007 @ 10:34:
[...]


Nou als ik in Java iets schrijf dan werk ik meestal netjes per klasse in een losse file, of soms als het heel nauw samenhangt in een file. Ga je dat in PHP doen, dan moet je veel te veel losse includes doen. Ga je al die includes samenvoegen in een grote file, heb je daar weer een performance hit op op het moment dat je maar een klein beetje van die functionaliteit nodig hebt.

Sorry hoor maar die paar requests naar het filesystem binnen een __autoload() om de juiste class in te laden zou niet meer of minder performance mogen kosten dan bij java waar je ook overal verschillende imports hebt (xml files inlezen, jars uitpakken, etc)

Ik heb er ook nog nooit überhaupt 1 ding van gemerkt dat het trager wordt door een autoload te gebruiken dus daar zou ik me niet door laten tegenhouden.

[BikkelZ]

SchizoDuckie schreef op vrijdag 08 juni 2007 @ 10:41:
[...]


Sorry hoor maar die paar requests naar het filesystem binnen een __autoload() om de juiste class in te laden zou niet meer of minder performance mogen kosten dan bij java waar je ook overal verschillende imports hebt

Ik heb er ook nog nooit überhaupt 1 ding van gemerkt dat het trager wordt door een autoload te gebruiken dus daar zou ik me niet door laten tegenhouden.

Ik heb vrij weinig zin om het verschil tussen gecompileerde en niet gecompileerde code uit te gaan leggen aan iemand die me met smileys loopt te bestoken, maar je mag best Googlen van me.

[Janoz]

Hmm, in jouw opinie is alle classes enorm bloated maken een stuk efficienter dan een paar lean en mean specifiek op hun taak toegepaste classes maken? Vreemde aanname als je het mij vraagt. Je beweert dat je bepaalde functionaliteit in 80% van je classes nodig hebt. Hieruit maak ik op dat je zo goed als zeker kunt zijn dat in jouw geval alles ingeladen wordt. Er zal immers altijd wel een class zijn die je bij dat specifieke request gebruikt waardoor je al die functionaliteit naar binnen schuift.

Wat is dan het probleem om het niet ietsje meer op te splitsen en daadwerkelijk wat fatsoenlijk aan het werk gaat? ipv het compleet toevoegen van error afhandeling aan ELKE class kun je natuurlijk ook gewoon 1 error object per request aanmaken en deze overal gebruiken. Lijkt mij een stuk efficienter.

Daarnaast ben ik van mening dat je je blind loopt te staren op pure execution performance (nee sterkern nog assumed execution performance!). Je bent de onderhoudbaarheid compleet uit het oog verloren in je streven naar een aangenomen perfectie. Wat je uiteindelijk zult zien is dat die bloated classes nogal tight coupled worden waardoor het onderhoud erg lastig worden en de reusability sterk zal verminderen.

Owh, en het enige antwoord dat je blijkbaar wilt horen is: Afaik kun je niet dergelijke prototype constructies toepassen en zul je inderdaad moeten gaan extenden.

[ Voor 6% gewijzigd door Janoz op 08-06-2007 10:56 ]

[BikkelZ]

OK, thnx. Het zal nog wel even duren voordat PHP zoiets gaat ondersteunen denk ik ook.....

---------------

Ik heb vrij weinig zin om me nog verder te gaan verdedigen, aangezien deze discussie de beantwoording van mijn vraag alleen maar ondersneeuwt. Blijkbaar is het nogal een gevoelig punt bij veel mensen als ik zeg dat Java beter is dan PHP in OO. OK, sorry dat ik je gekwetst heb dan. Type hinting is trouwens ook totaal niet brak. En het is gezond in een echt OO systeem een variabele de ene keer een int is en de volgende keer zomaar een Object kan zijn. En ik wil ook hierbij mijn excuses aanbieden aan de mensen die in tegenstelling tot mij weten dat niet-(voor)gecompileerde code net zo snel en efficient uitgevoerd wordt als wel gecompileerde code. Wederom moest ik diep door het stof.

Nu ik mijn welgemeende excuses heb aangeboden, rest er nog een vraag:

Prototypes als Object aanpassen in PHP, kan het, of het kan het niet?


(serieus, als ik weet dat er in iedere instantie van een klasse potentieel iets fout kan gaan, en ik wil dat netjes eerst in de instantie opvangen, zodat ik en iedereen die refereert naar hem weet of dat er een fout is opgetreden in die instantie of niet, voordat ik hem doorpass naar een centrale singleton class voor verdere afhandeling, dan moet ik dat echt zelf weten.)

[ Voor 4% gewijzigd door BikkelZ op 08-06-2007 11:15 ]

[Creepy]

Dat moet je uiteraard ook zelf weten Maar het is niet dat wij hier allemaal maar een stelletje prutsers zijn dus misschien dat je iets met het advies kan doen om het niet in je class op te nemen maar je class een andere class te laten gebruiken. En of je dat doet of niet moet je uiteraard helemaal zelf weten.
Ook ik vindt het vreemd dat je deze keuze maakt op de aanname dat het elke keer includen van meerdere files merkbaar trager is.

Als je de Object class wilt aanpassen dan zul je PHP zelf moeten aanpassen en opnieuw moeten compilen. Ook bijv. in Java kan je de Object class niet zomaar aanpassen. Er zijn overigens maar weinig omgevingen/talen die dat toestaan. Uiteraard werkt je code dan ook alleen in jouw specifieke PHP versie.

[ Voor 14% gewijzigd door Creepy op 08-06-2007 11:34 ]

[BikkelZ]

Creepy schreef op vrijdag 08 juni 2007 @ 11:31:
Dat moet je uiteraard ook zelf weten Maar het is niet dat wij hier allemaal maar een stelletje prutsers zijn dus misschien dat je iets met het advies kan doen om het niet in je class op te nemen maar je class een andere class te laten gebruiken. En of je dat doet of niet moet je uiteraard helemaal zelf weten.
Ook ik vindt het vreemd dat je deze keuze maakt op de aanname dat het elke keer includen van meerdere files merkbaar trager is.

Nee dat is een zij-discussie die ik helemaal niet wilde voeren eigenlijk. De reden dat ik het wilde doen is omdat het a) in sommige talen wel kan (oftewel puur nerdisme) en b) ik er een toepassing voor zou kunnen hebben omdat ik spontaan het idee kreeg dat het wel handig zou zijn om te weten of er per instantie van een klasse iets fout is gegaan in plaats van dat ik alle errors op een grote hoop gooi meteen. Zo geef je een instantie ook de mogelijkheid om altijd zijn eigen error te laten zien en voortijdig van de stapel met te showen errors af te kunnen trekken.

Creepy schreef op vrijdag 08 juni 2007 @ 11:31:Als je de Object class wilt aanpassen dan zul je PHP zelf moeten aanpassen en opnieuw moeten compilen. Ook bijv. in Java kan je de Object class niet zomaar aanpassen. Er zijn overigens maar weinig omgevingen/talen die dat toestaan. Uiteraard werkt je code dan ook alleen in jouw specifieke PHP versie.

Zo ver was ik vandaag nog even niet van plan om te gaan

[Janoz]

...als ik zeg dat Java beter is dan PHP in OO.

Ah, dan is er iig iets waar we het laaiend over eens zijn. Hoe php OO geimplementeerd heeft zou ik ronduit als brak omschrijven, en de manier hoe ze dat in php5 proberen recht te breien is weer net zo'n aanfluiting. Ik zie echter nauwlijks opmerkingen van op de teentjes getrapte mensen die hun eigen kamp aan het verdedigen zijn. Ik snap dus niet helemaal wat je nu met de rest vna je allinea probeert te zeggen.

ik er een toepassing voor zou kunnen hebben omdat ik spontaan het idee kreeg dat het wel handig zou zijn om te weten of er per instantie van een klasse iets fout is gegaan in plaats van dat ik alle errors op een grote hoop gooi meteen. Zo geef je een instantie ook de mogelijkheid om altijd zijn eigen error te laten zien en voortijdig van de stapel met te showen errors af te kunnen trekken.

Jij denkt dat het wel eens handig zou zijn. In dit topic wordt gezegd dat dat niet zo is. Er worden meerdere redenen aangedragen waarom het niet zo is terwijl jij nog nauwelijks redenen aangedragen hebt waarom het eventueel wel zo zou zijn. Ook wat je hier noemt is niet iets waarvan ik vindt dat dat niet mogelijk is met de aanpak waarbij je een class aan je class meegeeft en beide classes elk hun eigen verantwoordelijkheden hebben.

Jij wilt functionaliteit in je class implementeren. Ik zeg dat je die functionaliteit beter kunt injecteren. hiermee bereik je exact dezelfde functionaliteit. Je hebt misschien wel meer classes, maar deze classes zijn kleiner, overzichtelijker en voldoen beter aan het blackbox principe.

Geef mij een stukje code van iets dat jij denkt dat je middels je prototype manier wilt implementeren en ik laat je een net equivalent zien met exact dezelfde functionaliteit!

[Grijze Vos]

Kan erover heengelezen hebben, maar ik heb niet gezien dat ook maar een persoon heeft gezegd dat wat de TS wil doen ook gewoon bad practice is in een full fledged OO taal als Java.

Lees en leer alsjeblieft eens wat basisprincipes OOP, doe je jezelf en je collegae een ontzettend groot plezier mee...

En nee, je kunt het base object niet aanpassen, sterker nog, ik denk niet eens dat PHP onder de motorkap zoiets heeft als een base object.

[Verwijderd]

BikkelZ schreef op vrijdag 08 juni 2007 @ 10:34:
Java dat wordt gecompileerd en daardoor al geoptimaliseerd van te voren waardoor je dat soort problemen helemaal niet hebt.

Euh java source files worden omgezet naar bytecode, wat nagenoeg een 1 op 1 vertaling is naar een andere taal. Er zitten geen hippe optimalisatie slagen in. Wat dat betreft is java byte code net zo'n script taal als php.

[BikkelZ]

http://www.prototypejs.org/learn/extensions

Bovenstaande resultaten zijn ook te bereiken met standaard JS/DOM manipulaties. Er zijn een boel mensen die het niet prettig vinden dat prototypes als Element automatisch fundamenteel aangepast worden, ook in scripts buiten de Prototype library, maar toch is het zo'n beetje de meest gebruikte AJAX library. Ik gebruik hem alleen niet, om bovenstaande reden onder andere. Maar het kan en wordt volop gebruik van gemaakt.

Als ik het zelfde voorstel binnen PHP wordt alvast de pek opgewarmd en een paar kippen geplukt. Ik vind dat op zijn zachtst gezegd een beetje typisch.

En natuurlijk kun je alles op een andere manier oplossen, ik durf haast wel te stellen dat alles wat je met OO doet uiteindelijk ook wel zonder objecten kan.

Ondertussen heb ik gewoon een Prototype klasse gebouwd en daarvanuit extenden nu negen van de tien klassen.

[user109731]

BikkelZ schreef op vrijdag 08 juni 2007 @ 13:32:
Als ik het zelfde voorstel binnen PHP wordt alvast de pek opgewarmd en een paar kippen geplukt. Ik vind dat op zijn zachtst gezegd een beetje typisch.

En natuurlijk kun je alles op een andere manier oplossen, ik durf haast wel te stellen dat alles wat je met OO doet uiteindelijk ook wel zonder objecten kan.

Prototype based programming is een heel ander iets dan class-based (Java, PHP, etc.). De class-based aanpak is niet slechter, maar je moet je er wel even in verdiepen. Wat jij nu wilt is prototyping op een inferieure manier in PHP voor elkaar krijgen, maar dat kan niet: PHP is class-based dus moet je het daarmee doen (wat prima mogelijk is).

Ondertussen heb ik gewoon een Prototype klasse gebouwd en daarvanuit extenden nu negen van de tien klassen.

Zoals Janoz al zei: maar waarom dan? Vind je dat echt de netste oplossing? Nofi, maar denk je het als nieuwkomer echt al beter te weten dan de OOP goeroes met jarenlange ervaring? (btw, wat je eerder zei over errors scheiden, dat kan ook prima met __CLASS__, debug_backtrace(), etc.)

[ Voor 40% gewijzigd door user109731 op 08-06-2007 13:53 ]

[BikkelZ]

De reden om het zo te doen is omdat het ook gaat om de staat waarin het object zich bevindt, wat een eigenschap is, en daardoor is het juist in stricte OO zo dat het in die klasse hoort. Het gaat er niet om wat ik precies met een foutmelding doe, maar of er uberhaupt een foutmelding opgetreden is in die instantie van die klasse. Ik had de oplossing die steeds aangedragen wordt al, die lijkt me vrij standaard.

----------

Ik ben nog eens wat gaan snuffelen, en blijkbaar lopen er meer imbecielen als ik rond:

http://www.robotics.utexa...eference/HTML/a00736.html

Wat zou die Base class doen?.....vast een stelletje amateurs.

[ Voor 23% gewijzigd door BikkelZ op 08-06-2007 14:05 ]

[BikkelZ]

En toch ben ik benieuwd hoe half en brak PHP7 prototypes gaat implementeren.

[Michali]

BikkelZ schreef op vrijdag 08 juni 2007 @ 10:34:
Nou als ik in Java iets schrijf dan werk ik meestal netjes per klasse in een losse file, of soms als het heel nauw samenhangt in een file. Ga je dat in PHP doen, dan moet je veel te veel losse includes doen. Ga je al die includes samenvoegen in een grote file, heb je daar weer een performance hit op op het moment dat je maar een klein beetje van die functionaliteit nodig hebt. Ik moet wel heel eerlijk zeggen dat ik nog niet met optimizers er op gedoken ben, maar dat was waar ik en andere mensen met mij wel tegen aan lopen of gelopen zijn.

Hier ben ik inderdaad ook tegenaan gelopen. Een optimizer cached de geparste/gecompileerde code, zodat deze stap in volgende requests overbodig wordt. De tijd van het parsen van een pagina kun je dan verwaarlozen.

Het probleem van waar je je klassen stopt heb ik ook, naar mijn mening, redelijk goed opgelost. Ik heb een script geschreven die een bepaalde directory (de dir waar alle bestanden met klassen in staan) doorzoekt naar classes en interfaces. Op basis van die informatie genereer ik dan weer een bestand (genaamd classes.php), die alle bestaande classes en het bijbehorende pad bevat (in een PHP array). Ook zit in dat bestand gelijk een __autoload die op basis van die array dan een include uitvoert. Op deze manier kan ik dus bestanden en klassen aanmaken zoveel ik wil, ik hoef alleen even het script aan te roepen en ik kan ze gebruiken waar ik wil. Werkt erg goed.

Java dat wordt gecompileerd en daardoor al geoptimaliseerd van te voren waardoor je dat soort problemen helemaal niet hebt. Bovendien blijft de gemiddelde Java thread toch echt langer in leven dan de gemiddelde PHP thread, waardoor het veel logischer wordt dat al je classes een keer aan bod komen.

Of Java werkelijk sneller is op dit gebied weet ik niet. Via de methode die ik beschreven heb is de performance gewoon goed. Via __autoload zorg je ervoor dat alleen die classes geladen worden die je gebruikt (en classes die in hetzelfde bestand staan natuurlijk, daar kom je niet omheen).

[whoami]

BikkelZ schreef op vrijdag 08 juni 2007 @ 13:32:
En natuurlijk kun je alles op een andere manier oplossen, ik durf haast wel te stellen dat alles wat je met OO doet uiteindelijk ook wel zonder objecten kan.

Even offtopic maareh .....
Waarom heet het Object Oriented denk je ?

Ok; even je post verkeerd geinterpreteerd, maar, waarom zou je dat dan willen ?
Wat Janoz zegt is wel waar, en daar had ik ook aan gedacht: injecteer de service die je wilt aanbieden in de classes die ze nodig hebben.

[ Voor 24% gewijzigd door whoami op 08-06-2007 14:14 ]

[BikkelZ]

Die optimizer daar zou je best eens gelijk in kunnen hebben, zo gauw je dat soort dingen gaat precachen heb je er minder last van. De oude methode van PHP was toch meer autistisch alles opnieuw uitvoeren en ter plekke keer op keer weer het zelfde bestand gaan includen. Dat heeft bij mij een keer tot een "Ai..." moment geleid toen ik ging vergelijken hoe de performance met losse includes en maximale flexibiliteit en totale OO en een compromis waarbij ik wat minder includes had.

[drm]

Ben ik de enige die benieuwd is naar de inhoud van de functies (methodes) die BikkelZ aan de "Prototype" class wil toevoegen?

't Is misschien wat flauw, maar misschien dat dat wel het punt een beetje duidelijker maakt?

[Creepy]

BikkelZ schreef op vrijdag 08 juni 2007 @ 13:58:
----------

Ik ben nog eens wat gaan snuffelen, en blijkbaar lopen er meer imbecielen als ik rond:

http://www.robotics.utexa...eference/HTML/a00736.html

Wat zou die Base class doen?.....vast een stelletje amateurs.

Ze maken daar een eigen class en laten al hun classes daar vanaf overerven. Iets wat ook prima kan in bijv. PHP (en elke andere OO taal). Dat is wat mij betreft fundamenteel anders dan de standaard class willen aanpassen. Waarom ze het doen is me niet helemaal duidelijk maar aangezien je dit als voorbeeld aandraagt weet je dit waarschijnlijk wel?
Waarom wil je deze oplossing eigenlijk niet gebruiken?

Tuurlijk, alles wat je OO kan oplossen kan je ook niet OO oplossen. Er zijn meerdere paradigma's. PHP heeft gekozen voor het OOP gebeuren.

[BikkelZ]

Ik ben nu thuis, maar het is ongeveer zoiets:

PHP:

<?php
class Prototype
{
    var $erroneous = false;
    var $error = null;
    var $errorHandler = null;
    
    function __construct()
    {
        $this->errorHandler =& ErrorHandler::getInstance();
    }
    
    function throwError($error)
    {
        $eh =& ErrorHandler::getInstance();
        if (is_a($error, 'Exception'))
        {
            $this->error = $error;
            $this->errorHandler->addError($error);
        }
        else
        {
            $this->errorHandler->addError('Exception exception');
        }
    }
    
    function isErroneous()
    {
        return $this->erroneous;
    }
    
    function getError($unstack = false)
    {
        if ($unstack)
        {
            $this->errorHandler->removeError(&$this->error);
        }
        return $this->error;
    }
}

class SQL extends Prototype
{
    var $sql_errno = 0;
    
    function throwError($sql_errno, $exception)
    {
        $this->$sql_errno = $sql_errno;
        parent::throwError($exception);
    }
    
    function getSQLErrno()
    {
        return $this->sql_errno;
    }
}
?>

Over de inhoud van de functies en klassen valt waarschijnlijk best te debatteren, maar de crux van het verhaal is dat ik van ieder object kan opvragen of er iets fout gegaan is en wat er fout gegaan is. Dit is verder ook geen geteste code, puur een voorbeeldje van hoe het ongeveer zou lopen.

[ Voor 3% gewijzigd door BikkelZ op 09-06-2007 11:57 ]

[XWB]

Als je dan toch OO gaat kan je het maar beter goed doen. Var vervangen door private en de functies protected maken.

PHP:

class Prototype
{
    private $erroneous = false;
    private $error = null;
    private $errorHandler = null; 

    public function __construct() { }
    
    protected function throwError($error) { }

    // enzovoort
}

[ Voor 8% gewijzigd door XWB op 09-06-2007 12:29 ]

[prototype]

BikkelZ, niet alleen zou ik je aanraden om je verder te verdiepen in paradigma's als OO --en niet alleen maar het denken in classes en methods-- maar ook principes als seperation of concerns onder de knie krijgen. En dan in het bijzonder nu aspect orientatie (AOP).

Het klassieke schoolvoorbeeld is daarbij loggen, hetgeen dat je wil. Het punt is dat logger code eigenlijk geen deel uitmaakt van je business logica, en dat het desondanks dat toch vervuilen van je business logica ermee serieuze implicaties heeft.

Niet alleen pas je door inheritance de sterkste vorm van coupling toe (met alle dependency en structurele stugheden erbij), je code wordt ook een stuk lastiger te onderhouden met die 'error logger vervuilingen'. Laatstgenoemde zijn immers alsnog lijntjes code, en in het bijzonder lijntjes code die b.v. helemaal niet echt iets te maken hebben met wat een database class zou moeten doen.

Je hebt nu te maken dus met een crosscutting concern in de zin dat je code zowel tangled als scattered zou kunnen zijn. Eerstgenoemde spreekt voor zich, i.e. dat logger code binnen je business logica verweven zit (waar jij tegenaan zit te kijken), en scattered houdt in dat als je b.v. de logger nog in een class hebt verwerkt en die over (meerdere) verschillende packages verspreid/nodig hebt.

Met aspect orientatie pak je dit nu anders aan door een aspect voor je probleem te schrijven, wat kort door de bocht neerkomt op een advies schrijven die aangeroepen moet worden op bepaalde punten binnen je code. Een weaver weeft dan vervolgens deze aspecten met je business logica in gecompileerde vorm af. Het gevolg ervan is dus dat je in je gecompileerde versie dus welliswaar je logger code hebt verweven met je business code, in je sources echter -niet-.

Voor zover ik weet bestaan er wel een paar aspect orientatie frameworks voor PHP, en anders kan je er zelf ook altijd een schrijven. Met reflection zou je nog best een eind kunnen komen om het te implementeren iig.

[PrisonerOfPain]

[b][message=28185675,noline]Ook bijv. in Java kan je de Object class niet zomaar aanpassen. Er zijn overigens maar weinig omgevingen/talen die dat toestaan. Uiteraard werkt je code dan ook alleen in jouw specifieke PHP versie.

Javascript, Ruby, Squak (Smalltalk), Ruby, Perl en C# 3.0 kan ik zo al opnoemen die dit soort dingen ondersteunen. Zo exotisch is het dus eigenlijk helemaal niet . In PHP kun je ook dynamisch methods toevoegen mits je geen bezwaar hebt tegen een dependency op een extension.

[BikkelZ]

OK, duidelijk verhaal.

Als ik niet op het niveau van de (instantie van de) class bijhoud of...

PHP:

errorHandler::addError($error);

...direct of indirect aangeroepen is, hoe weet ik dan of er iets fout is gegaan in bvb mijn instantie van de SQLQuery class, dat ik hem dus wel of niet kan gebruiken, en mocht het me op dat punt nog interesseren, welke SQL error er opgetreden is (een duplicate key is iets wat je anders wil afvangen in je uiteindelijke uitvoer dan een table die niet gevonden kan worden)?

Dat iedere simpele class extenden lastig is, is ook de reden dat ik deze topic uberhaupt open. Kijk als je in PHP een hashcode wilt van een object, dan moet je altijd zelf ergens iets gaan bouwen, terwijl je in Java dat bij iedere klasse gewoon standaard op kan vragen. Verwacht ik dat ik toch in de meeste classes iets wil gaan doen met hashcodes, hoe doe ik dat dan?

De vraag is voor mij ook veel meer theoretisch, terwijl er meteen heel erg naar de praktijk gekeken wordt omdat mijn voorbeeld misschien niet zo sterk was.

(En misschien is het wel beter om een isDuplicateKey() achtige check te gebruiken dan een specifieke Oracle-, MySQL of BDB errornummer op te vragen trouwens, weer een ander verhaal)

-----------

typo

[drm]

als je dan toch PHP5 gebruikt, waarom throw je dan niet gewoon exceptions? Dan kan je ook veel beter bepalen wie de verantwoordelijkheid voor de exceptions draagt.