[php] classes - ideaal?

[Verwijderd]

Ik ben zelf bezig met een CMS (Content Management System)
Nou is mijn bedoeling om alles in classes te doen.
Bijvoorbeeld een class voor het menu, een class voor de opmaak, een class voor nieuws, enz. enz. Het liefst zou ik het zo maken dat als je die class in een directory zet, dat alles automagisch wordt ingelezen en gebruikt in je script. Maar helaas zul je op een gegeven moment dingen handmatig moeten instellen. Heeft iemand ervaring hiermee, want ik wil namelijk proberen alles automatisch te laten lopen

Ik zit bijvoorbeeld te denken aan een functie in elke class die alle beschikbare functies inclusief parameters retourneert. Hoe ver moet je hier in gaan???

[Creepy]

Op dinsdag 06 november 2001 12:36 schreef ceidhof het volgende:
Ik zit bijvoorbeeld te denken aan een functie in elke class die alle beschikbare functies inclusief parameters retourneert. Hoe ver moet je hier in gaan???

Ik denk dat dit te ver gaat.. je maakt neem ik aan eerst een klasse-diagram voordat je gaat programeren? Dan weet je al (voordat je gaat programeren) welke classes welke methods en properties hebben.

Als je van een object eerst moet gaan vragen wat voor methods die heeft, hoe parse je dat dan? Dan weet je nog steeds niet waar elke method voor dient..

[Verwijderd]

Nee daarom.
Als je het vol-automatisch wilt maken, loop je tegen ontzettend veel problemen aan. Maar het is in principe te doen. Je vraagt gewoon aan elke class welke functies die heeft, en per functie een aantal variablen. Opzich kan je ook wel iets bouwen wat alle beschikbare (algemene) variablen aangeeft, en dan kan je dat weer aan mekaar koppelen. Of ga ik nou iets te ver?

[Creepy]

Heheh.. naar mijn idee ga je wat te ver daar mee, maar dat is puur MIJN mening..

Ach.. wat doe je met een lijst van methods als je die hebt.. ze allemaal aanroepen ofzo?? Of definieer je een aantal vasta methods en vraag je daarna aan het object welke van deze methods ze hebben? Dat zou goed kunnen.
Maar nogmaals.. als je zelf al je objecten maakt weet je al welke methods ze hebben.. dus waarom het nog gaan vragen?
Of moeten andere mensen er zelf nieuwe objecten in kunnen hangen (ala plugins ofzo). Dan is dat goed te gebruiken. Maar defineer wel van te voren alle mogelijke methods.. anders kan je er zo weinig mee

[mbravenboer]

ceidhof: Ik zit bijvoorbeeld te denken aan een functie in elke class die alle beschikbare functies inclusief parameters retourneert. Hoe ver moet je hier in gaan???

Dan ben je in feite bezig met het implementeren van reflectie/runtime type informatie.

Over het algemeen wordt reflectie niet gezien als een mooie design oplossing. Je kan vaak met behulp van een goed OO design makkelijk bereiken wat jij wilt qua flexibiliteit en polymorfisme. Je gaat denk ik wel een beetje naar het randje van de mogelijkheden van PHP.

[Verwijderd]

Ja ik weet het zelf ook niet, op zich zou het wel een ideaal systeem qua onderhoud zijn. Sleur en pleur een bestandje in een directory en je hebt een update van je bestaande systeem

[GraasGast]

ik gebruik een beetje een dergelijk systeempje...

in al m'n scripts include ik een script base.php

daarin staan alle config instellingen, en daarin worden een hoop andere files geinclude, zoals base.template.php, base.db.mysql.php en base.img.php enz...

werkt geniaal

[mbravenboer]

Eigenlijk zou je hiervoor Java moet gebruiken met dynamic clas loading. Als je dit probleem op deze manier wilt oplossen schreeuwt dynamic class loading om gebruikt te worden .

[tomato]

mbravenboer:
Eigenlijk zou je hiervoor Java moet gebruiken met dynamic clas loading. Als je dit probleem op deze manier wilt oplossen schreeuwt dynamic class loading om gebruikt te worden .

Het gaat hier nog steeds over PHP hoor

En Java is niet de enige OO taal

[Verwijderd]

Als je in een class een functie zet met dezelfde naam als de class, dan wordt deze direct uitgevoerd als je een nieuwe instantie van die class genereert.

Wellicht heb je hier iets aan ...
Je zou dan de overige functies uit die class in die gelijknamige functie kunnen aanroepen.

Patrick

[tomato]

Op woensdag 07 november 2001 15:41 schreef FourEyes het volgende:
Als je in een class een functie zet met dezelfde naam als de class, dan wordt deze direct uitgevoerd als je een nieuwe instantie van die class genereert

Dat noemt men een constructor en ik geloof niet dat dat iets is waar ceidhof op doelt

[McVirusS]

Classes voor verschillende site onderdelen???

Kan je dan niet beter met templates en includes werken? Een database/template class......okay.......maar een class om het menu te defineren

[mbravenboer]

tomato: Het gaat hier nog steeds over PHP hoor

Daarom zei ik ook even dat je hiervoor eigenlijk Java moet gebruiken .

En Java is niet de enige OO taal

Joh . Het is wel een van de weinige talen (hum, eigenlijk platformen) die zo makkelijk dynamic class loading biedt.

[tomato]

Op woensdag 07 november 2001 16:40 schreef mbravenboer het volgende:
Het is wel een van de weinige talen (hum, eigenlijk platformen) die zo makkelijk dynamic class loading biedt.

Python en C++ (ok, niet direct) bieden het ook. C# niet (komt nogal eens naar voren in Java-C# vergelijkingen).

[mbravenboer]

[quote]
mbravenboer: Het is wel een van de weinige talen (hum, eigenlijk platformen) die zo makkelijk dynamic class loading biedt.

tomato: Python en C++ (ok, niet direct) bieden het ook.

Java is en blijft toch het platform waar het het makkelijkst en het veiligst te verwezelijken is .

tomato: C# niet (komt nogal eens naar voren in Java-C# vergelijkingen).

Hum, nog geeneens bij stil gestaan. Je kan toch wel via reflectie instanties aanmaken? Je kan ook at-runtime code compileren en laden (gebeurt bijvoorbeeld bij de regex). Ik vraag me dus eigenlijk af wat er precies niet mogelijk zou moeten zijn? Bovendien zou dit niet echt C# afhankelijk zijn, maar .NET afhankelijk toch?

Ik heb nog niet veel met reflectie en zulke toestanden gewerkt, dus ik kan wel iets gemist hebben .

[mbravenboer]

Ik heb ff een C# boekje erbij gepakt, maar het is toch echt mogelijk hoor... Ik zie allerlei dingen gebeuren die ook in Java mogelijk zijn: Assembly laden van een file, types eruit halen, instanties maken en methoden aanroepen (eventueel via een interface...). Lijkt mij dus geen probleem?

[tomato]

mbravenboer: Java is en blijft toch het platform waar het het makkelijkst en het veiligst te verwezelijken is .

Okay, jij je zin (als in "je hebt gelijk" )

Hum, nog geeneens bij stil gestaan. Je kan toch wel via reflectie instanties aanmaken? Je kan ook at-runtime code compileren en laden (gebeurt bijvoorbeeld bij de regex). Ik vraag me dus eigenlijk af wat er precies niet mogelijk zou moeten zijn? Bovendien zou dit niet echt C# afhankelijk zijn, maar .NET afhankelijk toch?

Het zou volgens mij inderdaad .NET afhankelijk zijn. Ik zit ook even te zoeken waar ik dit tegengekomen ben, maar het is al een tijdje terug. Wordt C# niet statisch gecompileerd in tegenstelling tot Java en is dynamic class loading daarom niet alleen via bijv een DLL mechanisme mogelijk
Alles wat ik er nu zo snel over kan vinden zijn opmerkingen als "C# kent geen dynamic class loading" en uitgebreidere stukken waaruit ik alleen maar zou kunnen concluderen dat C# het weer wel kent (maar waarin het niet expliciet genoemd wordt )...

Ik heb nog niet veel met reflectie en zulke toestanden gewerkt, dus ik kan wel iets gemist hebben .

Denk je dat ik hier meer ervaring dan jij mee heb?

[tomato]

Op woensdag 07 november 2001 17:29 schreef mbravenboer het volgende:
Ik heb ff een C# boekje erbij gepakt, maar het is toch echt mogelijk hoor... Ik zie allerlei dingen gebeuren die ook in Java mogelijk zijn: Assembly laden van een file, types eruit halen, instanties maken en methoden aanroepen (eventueel via een interface...). Lijkt mij dus geen probleem?

Okay, you're right. Maar waarom ik dan meerdere keren een tegengestelde bewering tegenkom...
Zeker mensen die er niets vanaf weten (kijk niet naar mij )

[mbravenboer]

tomato: Okay, jij je zin (als in "je hebt gelijk" )

Daar doen we het voor .

Wordt C# niet statisch gecompileerd in tegenstelling tot Java en is dynamic class loading daarom niet alleen via bijv een DLL mechanisme mogelijk

Hum, daar weet ik eerlijk gezegd ook niet het fijne van. Feit is in ieder geval dat IL sterk te vergelijken is met Java bytecode. Voor zover ik het nu zie, kan je gewoon elke assembly at runtime onderzoeken. Assemblies bevatten nogal wat metadata die gebruikt wordt. Ik zie in ieder geval niet in waarom C# 'statischer' gecompileerd wordt dan Java.

Ik versta onder dynamic class loading het instantieren van een object van een klasse die at-runtime wordt verwerkt en at compile-time niet beschikbaar was. In Java kan dat op een fraaie manier van de ClassLoader, in .NET is er volgens mij geen ClassLoader (misschien dat dat dus wordt bedoeld). Je kunt echter ook zonder ClassLoader gewoon at-runtime assemblies onderzoeken en klassen instantieren.

Wat ik nog niet heb gezien is het laden van een klasse uit een willekeurige bron via een byte[]. Dat is met het class loading wel mogelijk. Ik denk dat het hier dus om gaat. Je kunt in ieder geval in .NET wel op een fraaie manier at-runtime code generen en compileren. Dat is natuurlijk ook een zeer interessante optie en vaak een betere keuze dan reflectie. Sun heeft hier al vrij snel op gereageerd. De Java Compiler mag nu namelijk ook met de JRE worden gedistribueerd (was eerst niet toegestaan). Nu nog wachten op de standaard opname van de Java Compiler in de JRE .

Denk je dat ik hier meer ervaring dan jij mee heb?

Ach, het is een kwestie van stukken bekijken . Ik heb me niet intensief bezig gehouden met alle aspecten van .NET, dus ik ben niet zo heel erg bij .

tomato: Maar waarom ik dan meerdere keren een tegengestelde bewering tegenkom...

Misschien wordt dus hetgene bedoeld wat ik hierboven noem. Of dat nu echt een groot punt is betwijfel ik en het is meer de vraag wat je onder dynamic class loading verstaat... Voorlopig zie ik geen hele grote verschillen tussen het Java Platform en .NET. Het ClassLoader mechanisme is echter wel erg fraai en het is ook wel jammer dat dat (voor zover ik weet) niet is meegenomen in .NET. Merkwaardig wel, want het is 1 van de meeste geprezen aspecten van Java.