[PHP] OO, Polymorphisme, etc mogelijkheden *

[T-MOB]

Modbreak:

Dit topic is afgesplits van [rml][ PHP] OOP structuur forum[/rml]

Alarmnummer schreef op woensdag 22 december 2004 @ 15:19:
Lijkt het je niet een stuk handiger dat je de oo concepten eerst even goed onder de knie probeert te krijgen ipv meteen een forum ermee in elkaar te plakken? Snap je uberhaubt wat polymorfisme, encapsulation, data hiding, en inheritance inhoud? Probeer dat eerst goed onder de knie te krijgen met een 'pure' oo taal.

Mwoah, dat vind ik wat kort door de bocht. Volgens mij hoef je - zeker als het voor je hobby is - niet eerst hele boekwerken door te nemen voor je wat kunt doen. IMO is gewoon proggen/scripten een prima manier om de boel onder de knie te krijgen. Helemaal als je steeds je eigen bouwsel probeert te verbeteren. Volgens mij is TS juist bezig om de oo concepten onder de knie te krijgen dóór zijn forum te verbeteren.
Om hem dan gelijk een bak profi buzzwords van het OO naar het hoofd te smijten en te zeggen dat hij die eerst maar moet leren (en ook nog een echte OO taal) vind ik dan een beetje flauw. Geef dan een linkje naar een inleiding of geef wat korte uitleg. Volgens mij ben jij namelijk een van de meest bezielde (is dat een juiste uitdrukking?) OO-programmeurs op het forum.

Zelf ben ik eigenlijk ook wel beniewd naar wat "oplossingen" voor TS zijn probleem. Zelf heb ik me nooit echt in de details van OO verdiept omdat ik er voor mijn PHP-bouwsels nooit heil in heb gezien.

[ Voor 5% gewijzigd door gorgi_19 op 22-12-2004 16:24 ]

[whoami]

Skaah, dat vind ik nu eens niet direct een goed voorbeeld van een singleton. Waarom moet je DAL een singleton zijn ? IMO is dat voor niks nodig.
Een DAL is stateless, en dus heeft het imo ook geen zin om 'm als singleton te definieren. Je DAL houdt toch geen state bij.

[Alarmnummer]

T-MOB schreef op woensdag 22 december 2004 @ 15:42:
[...]
Mwoah, dat vind ik wat kort door de bocht. Volgens mij hoef je - zeker als het voor je hobby is - niet eerst hele boekwerken door te nemen voor je wat kunt doen.

Dat ben ik voor een gedeelte met je eens. Maar als je toch een wat beter begrip van oo en patterns wilt hebben (of eigelijk uberhaubt begrijpen wat het voordeel is van oo) dan zou ik toch even kijken naar een wat serieuzere oo omgeving. Later kan je die kennis die je daar hebt opgedaan wel weer meenemen naar php.

Ik merkte trouwens aan antwoorden van de topicstarter dat hij het niet echt hoog op had met oo, dus vandaar mijn advies. Even uit het php gebeuren... even naar een schone oo taal.

[pjvandesande]

T-MOB schreef op woensdag 22 december 2004 @ 15:42:
[...]


Mwoah, dat vind ik wat kort door de bocht. Volgens mij hoef je - zeker als het voor je hobby is - niet eerst hele boekwerken door te nemen voor je wat kunt doen. IMO is gewoon proggen/scripten een prima manier om de boel onder de knie te krijgen. Helemaal als je steeds je eigen bouwsel probeert te verbeteren. Volgens mij is TS juist bezig om de oo concepten onder de knie te krijgen dóór zijn forum te verbeteren.
Om hem dan gelijk een bak profi buzzwords van het OO naar het hoofd te smijten en te zeggen dat hij die eerst maar moet leren (en ook nog een echte OO taal) vind ik dan een beetje flauw. Geef dan een linkje naar een inleiding of geef wat korte uitleg.

www.phppatterns.com dacht ik, daar kan de TS even een kijkje nemen.

Ik vind dat je hier voor een gedeelte wel gelijk hebt, maar het nivo op got is soms wat anders. Over het algemeen programeren de meeste hier niet alleen als hobby. Is het wel je hobby, lijkt het mij toch belangrijk en intressant om wat belangrijke punten van OOP design te kennen. Zeker de namen die Alarmnummer noemt moeten je toch wel iets zeggen.

Volgens mij ben jij namelijk een van de meest bezielde (is dat een juiste uitdrukking?) OO-programmeurs op het forum.

Zeker weten!

Zelf ben ik eigenlijk ook wel beniewd naar wat "oplossingen" voor TS zijn probleem. Zelf heb ik me nooit echt in de details van OO verdiept omdat ik er voor mijn PHP-bouwsels nooit heil in heb gezien.

Er loopt ergens een draadje over OO en PHP. Heel intressant, .Oisyn geeft hier een aantal goede argumenten (dat staat mij iig nog bij )

[Alarmnummer]

whoami schreef op woensdag 22 december 2004 @ 15:42:
Skaah, dat vind ik nu eens niet direct een goed voorbeeld van een singleton. Waarom moet je DAL een singleton zijn ? IMO is dat voor niks nodig.
Een DAL is stateless, en dus heeft het imo ook geen zin om 'm als singleton te definieren. Je DAL houdt toch geen state bij.

Dat ligt er aan. Je houdt misschien geen state van entities bij, maar er kan wel degelijk state worden bijgehouden. Oa connecties, cachen, noem maar op.

[Skaah]

whoami schreef op woensdag 22 december 2004 @ 15:42:
Skaah, dat vind ik nu eens niet direct een goed voorbeeld van een singleton. Waarom moet je DAL een singleton zijn ? IMO is dat voor niks nodig.
Een DAL is stateless, en dus heeft het imo ook geen zin om 'm als singleton te definieren. Je DAL houdt toch geen state bij.

Een singleton gebruik je wanneer je één instantie van een object nodig hebt. Met DBAL bedoel ik de 'laag' tussen je logica en de php functies zoals mysql_connect(). (bv:

PHP:

$db->update(TBL_USER,array('nick'=>'piet'),'user_id=3');

Althans, zo heb ik het opgepikt.

Ik snap niet precies wat je bedoelt met stateless, zou je daar iets over uit kunnen leggen? Waarom zou je geen singleton voor een DBAL kunnen gebruiken?

[whoami]

Alarmnummer schreef op woensdag 22 december 2004 @ 15:54:
[...]


Dat ligt er aan. Je houd misschien geen state van entities bij, maar er kan wel degelijk state worden bijgehouden. Oa connecties, cachen, noem maar op.

Ik ga nu wel offtopic, maar als je een beetje een schaalbaar systeem wilt opzetten, dan ga je aan connection-pooling doen. Dit houd dan in dat je je connectie sluit van zodra je ze niet meer nodig hebt. Je gaat dus geen state van je connectie bijhouden, je kan natuurlijk wel je connection gaan doorgeven als dit nodig is (als je bv. een 'master/child' insert oid wilt doen.

[Alarmnummer]

whoami schreef op woensdag 22 december 2004 @ 15:58:
Ik ga nu wel offtopic, maar als je een beetje een schaalbaar systeem wilt opzetten, dan ga je aan connection-pooling doen.

Uiteraard, maar daar ging het niet om.

Je gaat dus geen state van je connectie bijhouden, je kan natuurlijk wel je connection gaan doorgeven als dit nodig is (als je bv. een 'master/child' insert oid wilt doen.

Je houd objecten bij die nodig zijn van het functioneren van de DAL. De kans is groot dat dit niet al te veel zal zijn (afgezien van de caching).

[Skaah]

offtopic:
Hopelijk heeft de TS hier iets aan ;-)

[Grijze Vos]

Alarmnummer schreef op woensdag 22 december 2004 @ 15:19:
Lijkt het je niet een stuk handiger dat je de oo concepten eerst even goed onder de knie probeert te krijgen ipv meteen een forum ermee in elkaar te plakken? Snap je uberhaubt wat polymorfisme, encapsulation, data hiding, en inheritance inhoud? Probeer dat eerst goed onder de knie te krijgen met een 'pure' oo taal.

polymorfisme in php, check.
encapsulation en datahiding in php, check.
inheritance in php, check.

Ja, ik zie echt niet in hoe je met die basis concepten wil aantonen dat PHP geen goede taal is om dat in te doen. Dat je java fan bent prima, maar ga nou niet in elk PHP topic PHP lopen afbranden zonder enige zinnige redenatie.

[whoami]

Grijze Vos schreef op woensdag 22 december 2004 @ 16:09:
[...]

polymorfisme in php, check.
encapsulation en datahiding in php, check.
inheritance in php, check.

Serieus, heeft PHP polymorphisme ?

[Alarmnummer]

Grijze Vos schreef op woensdag 22 december 2004 @ 16:09:
[...]

polymorfisme in php, check.
encapsulation en datahiding in php, check.
inheritance in php, check.

Je moet mijn woorden niet uit hun context halen. Ik vraag of hij weet wat dat is en niet of het wel of niet in php aanwezig is. Als je dit soort concepten niet begrijp is het zowieso al ongelovelijk onzinnig om met patterns iets te gaan doen.

Ja, ik zie echt niet in hoe je met die basis concepten wil aantonen dat PHP geen goede taal is om dat in te doen.

Als je met dat soort dingen is het handiger om in een omgeving terecht te komen waar dit de normaalste zaak van de wereld is. En daar hoort php niet bij.

Dat je java fan bent prima, maar ga nou niet in elk PHP topic PHP lopen afbranden zonder enige zinnige redenatie.

En jij moet mijn tekst beter lezen en daarna pas commentaar leveren.

[ Voor 9% gewijzigd door Alarmnummer op 22-12-2004 16:14 ]

[Alarmnummer]

whoami schreef op woensdag 22 december 2004 @ 16:10:
[...]

Serieus, heeft PHP polymorphisme ?

Als het kan subclassen heeft het polymorfisme.

[Grijze Vos]

whoami schreef op woensdag 22 december 2004 @ 16:10:
[...]

Serieus, heeft PHP polymorphisme ?

Ja, tuurlijk. Functies kun je elk soort variabelen voeren, en je kunt verschillende types dus afhandelen op verschillende manieren. Dat is ad-hoc polymorfisme.

(als ik even polymorfistische functies bekijk.)

en het kan idd, zoals Alarmnummer net post ook subclassen.

[ Voor 16% gewijzigd door Grijze Vos op 22-12-2004 16:14 ]

[whoami]

Alarmnummer schreef op woensdag 22 december 2004 @ 16:00:
[...]

Uiteraard, maar daar ging het niet om.


[...]

Je houd objecten bij die nodig zijn van het functioneren van de DAL. De kans is groot dat dit niet al te veel zal zijn (afgezien van de caching).

Mjah, maar ga jij dan van iedere DAL - class een singleton maken ?

Mijn DAL bestaat bv uit een set van 'TableGateway' classes. Die classes doen niets anders dan een bepaald SQL statement uitvoeren, en de opgehaalde resultaten gaan teruggeven. Deze classes worden aangeroepen door de 'Business Logic' layer of een soort van 'remote facade'.
Dat je op je client een singleton maakt naar die remote facade, ok, maar toch niet van de DAL zelf.

_{misschien komt het wat warrig over; ben zelf ook niet meer helemaal helder.}

[Grijze Vos]

Alarmnummer schreef op woensdag 22 december 2004 @ 16:11:
[...]

Je moet mijn woorden niet uit hun context halen. Ik vraag of hij weet wat dat is en niet of het wel of niet in php aanwezig is. Als je dit soort concepten niet begrijp is het zowieso al ongelovelijk onzinnig om met patterns iets te gaan doen.

Over de zin van dit pattern in deze context wou ik sowieso nog wat zeggen, maar je punt klopt inderdaad.

Als je met dat soort dingen is het handiger om in een omgeving terecht te komen waar dit de normaalste zaak van de wereld is. En daar hoort php niet bij.

Onzin IMO. Pak een goed boek of een goede tutorial over OO concepten, en je kunt ze grotendeels ook prima in PHP aanpakken. Dit is echt jouw persoonlijke voorkeur die hier spreekt en niet een of andere rationeel antwoord.

En jij moet mijn tekst beter lezen en daarna pas commentaar leveren.

Nee, jij moet een taal die je niet aanstaat niet zonder reden afbranden.

[Alarmnummer]

Grijze Vos schreef op woensdag 22 december 2004 @ 16:13:
[...]


Ja, tuurlijk. Functies kun je elk soort variabelen voeren, en je kunt verschillende types dus afhandelen op verschillende manieren. Dat is ad-hoc polymorfisme.

Idd.. en net zoals coersion en casting overloading (was ff in de war met implicite en explicite casts) is het dus geen echte polymorfisme. Alleen alleen type parametrisatie en overerving zijn de enigste vormen van echte (universal) polymorfism.


Check
On understanding types, data abstraction, and polymorphism

voor uitleg over wat echte polymorfisme nu precies inhoud.

En jij moet mijn tekst beter lezen en daarna pas commentaar leveren.

Nee, jij moet een taal die je niet aanstaat niet zonder reden afbranden.

Ken je het begrip GIGO?

Als je een concept goed onder de knie wilt krijgen is het verstandig om een omgeving te hebben waarin die concepten ook goed worden toegepast. Java is vanaf het begin af aan al een oo taal geweest dus alle libraries zijn ook oo. Doordat je in zo`n concistente omgeving zit zie je ook beter het voordeel ervan. (Geld trouwens ook voor c# en in mindere mate c++ omdat c++ van oorsprong geen oo taal is). (Wil trouwens niet zeggen dat c++ geen oo taal is, maar c++ is zowel sterk in oo als in procedureel).

[ Voor 37% gewijzigd door Alarmnummer op 22-12-2004 16:30 ]

[gorgi_19]

En dit topic even afgesplitst van [rml][ PHP] OOP structuur forum[/rml] een discussie over de mogelijkheden van OO etc. in PHP en andere talen is erg leuk, maar voor het eigenlijke probleem niet interessant (aangezien termen als polymorphisme de topicstarter al vreemd waren )

[pjvandesande]

Grijze Vos schreef op woensdag 22 december 2004 @ 16:19:
[...]

Pak een goed boek of een goede tutorial over OO concepten, en je kunt ze grotendeels ook prima in PHP aanpakken. Dit is echt jouw persoonlijke voorkeur die hier spreekt en niet een of andere rationeel antwoord.

* pjvandesande wijst toch echt even hier naar: [rml][ php] Het nut van OO classes[/rml], daar word uw mening niet echt gedeelt.

offtopic:
Had Gorgi's veranderingen nog niet gezien...

[ Voor 13% gewijzigd door pjvandesande op 22-12-2004 16:30 ]

[simon]

Poeh, jullie maken het mij geens zins makkelijk. Ik weet dat PHP vrij gebrekkig is als het om OOP gaat, maar na een dergelijk begin aan een discussie vraag ik mij af of het voor mij, als hobbyist die OOP gebruikt als 'handig, leuk en netjes' om dan Java te gaan leren (server sided bedoelen jullie (jsp)). Maar nu even een andere vraag, in hoeverre is dit verbeterd in php 5 tov 4?

[Alarmnummer]

Simon schreef op woensdag 22 december 2004 @ 16:31:
Poeh, jullie maken het mij geens zins makkelijk. Ik weet dat PHP vrij gebrekkig is als het om OOP gaat, maar na een dergelijk begin aan een discussie vraag ik mij af of het voor mij, als hobbyist die OOP gebruikt als 'handig, leuk en netjes' om dan Java te gaan leren (server sided bedoelen jullie (jsp)).

JSP = geen serverside Java. JSP is niets anders dan HTML met embedded Java en daar wil je niet je hele applicatie in opzetten. Alleen het bovenste gedeelte van de weblaag kan je doen met JSP maar de rest is 'gewoon' java (en de hele zwik met gerelateerde serverside technieken heet dan ook wel j2ee (java 2 enterprise edition).

Maar nu even een andere vraag, in hoeverre is dit verbeterd in php 5 tov 4?

Ik had begrepen dat het kan extenden, dus een aantal basis principes van oo zou je zonder problemen kunnen toepassen. Ik weet niet of datahiding/encapsulation intussen echt goed werk, want het staat mij bij dat php zich niets aantrok van access modifiers.

[ Voor 11% gewijzigd door Alarmnummer op 22-12-2004 16:41 ]

[Michali]

Nou ik kan zeggen dat je in PHP5 toch echt zeker wel goed OO kan werken. Alles wat ik de laatste tijd heb gelezen over OO princiepes en patterns zijn perfect toe te passen binnen PHP. Alles wat je nodig hebt om een klein tot middel grote web app op te zetten kun je toepassen.

• interfaces
• abstracte klassen en functies
• method en veld scope
• statische functies en velden
• overerving
• getypeerde parameters (voor objecten)

Wat zou je nog meer nodig hebben?

Ik ben zelf twee apps geheel OO aan het opzetten en ik kan alles toepassen wat ik wil. Geen probleem.

[ Voor 10% gewijzigd door Michali op 22-12-2004 16:42 ]

[Janoz]

Wat voor nut heeft een connection pool of een singleton wanneer heel het php script alleen maar een request scope heeft?

[ Voor 5% gewijzigd door Janoz op 22-12-2004 16:53 ]

[simon]

Janoz schreef op woensdag 22 december 2004 @ 16:52:
Wat voor nut heeft een connection pool of een singleton wanneer heel het php script alleen maar een request scope heeft?

Hmm, als ik je goed begrijp zeg je dus dat het in princiepe geen nut heeft om dus een instance te behouden, maar wat nou als er in de constructor van die klasse dingen gebeuren enz? Dus als het een DBAL is en de connectie binnen die instance zit is het toch handig om een singleton te gebruiken?

[-FoX-]

Michali schreef op woensdag 22 december 2004 @ 16:40:
Alles wat ik de laatste tijd heb gelezen over OO princiepes en patterns zijn perfect toe te passen binnen PHP. Alles wat je nodig hebt om een klein tot middel grote web app op te zetten kun je toepassen.

Hmm.. interessant detail, klein tot middelgrote.. waarom geen grote?

Imho is het beter om OO technieken onder de knie te krijgen in een taal die hiervoor ontwikkeld is en je daardoor ook ergens dwingt om OO te gebruiken. PHP is dat niet.. je kan perfect OO en procedurele code door elkaar mixen en op die manier leer je het min of meer "fout" aan.

Ik heb nog niet zo lang geleden een volledige fundamentals cursus geschreven voor procedurele programmeurs en scripters.. ik zou deze misschien wel eens online kunnen zetten, mits een aantal kleine aanpassingen en indien er interesse is.

[marcusk]

Janoz schreef op woensdag 22 december 2004 @ 16:52:
Wat voor nut heeft een connection pool of een singleton wanneer heel het php script alleen maar een request scope heeft?

Een connection pool heeft sowieso zin omdat het ervoor zorgt dat db-verbindingen niet bij elke request opnieuw gemaakt hoeven te worden.

[edit]Oh, hmz.. maar als je alleen request scope hebt kun je de pool natuurlijk niet nuttig opslaan

Het nut van singletons (die je overigens uberhaupt niet moet gebruiken tenzij het niet anders kan) is denk ik inderdaad erg twijfelachtig bij PHP.

[ Voor 10% gewijzigd door marcusk op 22-12-2004 17:06 ]

[simon]

marcusk schreef op woensdag 22 december 2004 @ 17:04:
[...]
Een connection pool heeft sowieso zin omdat het ervoor zorgt dat db-verbindingen niet bij elke request opnieuw gemaakt hoeven te worden.

[edit]Oh, hmz.. maar als je alleen request scope hebt kun je de pool natuurlijk niet nuttig opslaan

Het nut van singletons (die je overigens uberhaupt niet moet gebruiken tenzij het niet anders kan) is denk ik inderdaad erg twijfelachtig bij PHP.

Als jij het nut bij PHP twijfelachtig vind, heb je dan andere ideën hoe het aan te pakken binnen PHP?

[Brakkie]

Janoz schreef op woensdag 22 december 2004 @ 16:52:
Wat voor nut heeft een connection pool of een singleton wanneer heel het php script alleen maar een request scope heeft?

Connection pools ben ik niet mee bekent. Voor vijvoorbeeld een database object kan het handig zijn als je zeker weet dat er in je script maar 1 instantie van aanwezig is.

Persoonlijk vind ik het werken met objecten binnen php voor mij overzichtelijke code opleveren en ik vind het een stuk makkelijker werken dan wanneer je een enorme verzameling functies hebt die je moet gaan includen. (includen van een class kan php tegenwoordig zelf als je hem instantieerd)

Kan het ook zijn dat het even geleden is dat verschillende mensen hier een blik geworpen hebben op de php manual. OOP functionaliteit wordt steeds uitgebreider. Wat is er mis met het werken met PHP in al dan niet volmaakte OOP style in niet al te grote projecten. Als het makkelijk en overzichtelijk werkt is het toch prima. Ik kan me soms best ergeren aan de Java "gelovigen" die in elk topic over PHP waar het ook maar naar OOP riekt beginnen te preken over de minderwaardigheid PHP in dat opzicht.

ow, hierbij een duidelijk overzichtje van de PHP5 OOP mogelijkheden: http://livedocs.phpdoc.in....php?l=en&q=language.oop5

[Koeniepoenie]

Simon schreef op woensdag 22 december 2004 @ 16:31:
Maar nu even een andere vraag, in hoeverre is dit verbeterd in php 5 tov 4?

Je kunt hier een heel stuk lezen over nieuwe mogelijkheden mbt OOP in PHP 5.

edit:
Eigenlijk dezelfde link als Brakkie post..

[ Voor 10% gewijzigd door Koeniepoenie op 22-12-2004 17:15 ]

[marcusk]

Simon schreef op woensdag 22 december 2004 @ 17:08:
Als jij het nut bij PHP twijfelachtig vind, heb je dan andere ideën hoe het aan te pakken binnen PHP?

Nouja, ik denk eigenlijk voornamelijk vanuit het oogpunt van Java. In PHP heb je niet dezelfde mogelijkheden om het gebruik van singletons te voorkomen. Maar een alternatief is om simpelweg de instantie van het object door te geven aan de (constructors v/d) objecten die het nodig hebben. Je zou (theoretisch ) ook een globale variabele kunnen gebruiken.

[Michali]

-FoX- schreef op woensdag 22 december 2004 @ 17:03:
[...]

Hmm.. interessant detail, klein tot middelgrote.. waarom geen grote?

Mischien niet zo kwa omvang, maar kwa complexiteit wel. Voor een echt complexe web app zul je ook wel eisen krijgen die mischien niet zo gemakkelijk te proggen zijn in php. Maar dat wil niet zeggen dat in php OO princiepes niet zijn toe te passen als wel het te stateless zijn van zulke apps. Als de startup gewoon te veel tijd kost en/of resources vreet, is het beter om voor iets anders te kiezen, zoals bijvoorbeeld Java met een web UI.

[ Voor 18% gewijzigd door Michali op 22-12-2004 17:43 ]

[Genoil]

Hmja daar gaan we weer...OOP in PHP5 vs. Java. Hoewel de lijst nadelen met de komst van PHP5 echt drastisch is verminderd, schijnt de "vreselijke" mogelijkheid tot het combineren van procedurele en OOP methoden toch nog steeds het voornaamste stokpaardje van de Javahova's te zijn om de PHP-boeren () mee om de oren te slaan. Met name het gevaar e.e.a. "fout" aan te leren schijnt toch de doorslag te geven om dappere PHP autodidacten die met OOP aan het klooien zijn naar Java door te verwijzen.

Wat een onzin!

Jullie zitten daar gerieflijk met jullie fijn geconfigureerde IDEs, relatief excentrieke Tomcats/JBosses of wat dan ook en waarschijnlijk een pittige IT opleiding achter de kiezen te prediken dat je geen OOP moet leren met PHP5 maar met Java moet beginnen...realiseren jullie de overhead die dat geeft?

De meeste PHPers hier zijn waarschijnlijk autodidacte hobbyisten en webdevelopers die alleen of in kleine teams werken aan kleine tot middelgrote dynamische websites. Degenen daarvan die wat verder zijn zoeken veelal naar mogelijkheden om structuur, overzicht en herbruikbaarheid aan te brengen in hun werk. PHP5-OOP is daar zoveel meer geschikt voor dan Java!

En dan is het in het begin misschien wat broddelwerk en niet helemaal volgens het boekje, maar daar zijn 'wij autodidacten' inmiddels wel aan gewend (en het werkt wel ;)!)...bovendien geloof ik niet dat de betere PHP5 boeken/tutorials qua OOP-basics onderdoen voor hun Java equivalenten.

Ik denk dat PHP5 de komende jaren zeker een stukje van de onderkant van de enterprise webapp markt gaat af snoepen waar J2EE en .NET nu nog domineren. Nu zie je daar nog niet zoveel van omdat PHP5 nog niet eens een jaar oud is. Maar de laagdrempeligheid, de enorme PHP4 userbase en de concurerende performance geven PHP5 kans op (onverwacht) groot succes.

[Alarmnummer]

Genoil schreef op woensdag 22 december 2004 @ 18:13:
Hmja daar gaan we weer...OOP in PHP5 vs. Java. Hoewel de lijst nadelen met de komst van PHP5 echt drastisch is verminderd, schijnt de "vreselijke" mogelijkheid tot het combineren van procedurele en OOP methoden toch nog steeds het voornaamste stokpaardje van de Javahova's te zijn om de PHP-boeren ()

Nee, want dan zouden we c++ ook moeten afbranden. Aangezien c++ een superset is van c.

Er zijn andere redenen waarom 'javahova (lees mensen met een gedegen opleiding die soms c++ohova en c#ohova zijn)) php bekritiseren.

De meeste PHPers hier zijn waarschijnlijk autodidacte hobbyisten en webdevelopers die alleen of in kleine teams werken aan kleine tot middelgrote dynamische websites. Degenen daarvan die wat verder zijn zoeken veelal naar mogelijkheden om structuur, overzicht en herbruikbaarheid aan te brengen in hun werk. PHP5-OOP is daar zoveel meer geschikt voor dan Java!

Zou je dit eens kunnen toelichten? Want ik zou niet weten wat voor betere oplossingen php heeft dan java/.NET for reuse.

En dan is het in het begin misschien wat broddelwerk en niet helemaal volgens het boekje, maar daar zijn 'wij autodidacten' inmiddels wel aan gewend (en het werkt wel ;)!)...bovendien geloof ik niet dat de betere PHP5 boeken/tutorials qua OOP-basics onderdoen voor hun Java equivalenten.

Ik ben ook als autodidact beginnen en ik ben het nog steeds. Ik lees echter wel een enorme zwik met boeken om vertrouwd te raken met alle problematiek die bij enterprise applicaties horen. Niet iedere applicatie is een directie interface over een database heen.

Ik denk dat PHP5 de komende jaren zeker een stukje van de onderkant van de enterprise webapp markt gaat af snoepen waar J2EE en .NET nu nog domineren. Nu zie je daar nog niet zoveel van omdat PHP5 nog niet eens een jaar oud is. Maar de laagdrempeligheid, de enorme PHP4 userbase en de concurerende performance geven PHP5 kans op (onverwacht) groot succes.

Hmmm tja, zo lang de grote bedrijven zoals Microsoft, IBM, BEA , Sun toch voornamelijk bij de .NET/Java kant blijven zie ik niet in waarom die in de toekomst veel klanten kwijt zullen raken.

Maar wat ik wel met je eens ben is dat php een laagdrempelige taal is waarmee veel mensen aan de slag kunnen gaan. En idd.. bijna iedere webhost heeft PHP support en dat kan je van Java/.NET niet zeggen.

Maar nogmaals.. er bestaan ook andere enterprise applicaties die meer zijn dan alleen een afspiegeling van een database.

[ Voor 7% gewijzigd door Alarmnummer op 22-12-2004 18:31 ]

[Verwijderd]

Genoil schreef op woensdag 22 december 2004 @ 18:13:
Hmja daar gaan we weer...OOP in PHP5 vs. Java. Hoewel de lijst nadelen met de komst van PHP5 echt drastisch is verminderd, schijnt de "vreselijke" mogelijkheid tot het combineren van procedurele en OOP methoden toch nog steeds het voornaamste stokpaardje van de Javahova's te zijn om de PHP-boeren () mee om de oren te slaan. Met name het gevaar e.e.a. "fout" aan te leren schijnt toch de doorslag te geven om dappere PHP autodidacten die met OOP aan het klooien zijn naar Java door te verwijzen.

Maak je niet druk, Java zelf is ook niet die helderste ster aan het firmament; overdesign is een serieus probleem voor een grote groep mensen die Java als eerste taal leert.

Om C.A.R. Hoare te citeren:

I conclude that there are two ways of constructing a software design:

One is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are no obvious deficiencies.

In mijn optiek gaat de typische "Javahova" zo goed als altijd voor de 2e optie (denkproces: "Ik heb die patterns dus ik zal ze gebruiken ook!")

[ Voor 3% gewijzigd door Verwijderd op 22-12-2004 18:31 ]

[Alarmnummer]

Verwijderd schreef op woensdag 22 december 2004 @ 18:30:
In mijn optiek gaat de typische "Javahova" zo goed als altijd voor de 2e optie (denkproces: "Ik heb die patterns dus ik zal ze gebruiken ook!")

Dan hou jij er een hele vreemde optiek op na. Een goed ontwerp is zo simpel mogelijk. Kijk eens naar de enorme collectie met java apen die je aantreft in de Agile stroming. Dus ik zou als ik jou was je mening even hierzien en in ieder geval geen genaraliserende uitspraken te doen.

J2EE is imho de grootste draak van Java en ja.. daarin is alles godsellendig complex, overdesigned, naar en vervelend. Maar er zijn ook lichte stromingen die komen opzetten... developers back in de driversseat ipv je over te moeten geven aan de grillen van een vreemde applicatieserver waarvan je maar een fractie van de functionaleit gebruikt. Spring is bv zo`n framework uit deze stroming en het is iets dat aan het aanslaan is.

Check verder mijn signature over hoe ik denk over complexiteit en check mijn 'anti-complexiteit' replies.

[ Voor 40% gewijzigd door Alarmnummer op 22-12-2004 18:35 ]

[marcusk]

Verwijderd schreef op woensdag 22 december 2004 @ 18:30:
Maak je niet druk, Java zelf is ook niet die helderste ster aan het firmament; overdesign is een serieus probleem voor een grote groep mensen die Java als eerste taal leert.

In mijn optiek gaat de typische "Javahova" zo goed als altijd voor de 2e optie (denkproces: "Ik heb die patterns dus ik zal ze gebruiken ook!")

Dat is dan een fout van de programmeur, niet van de taal. Je moet weten wanneer een bepaald design pattern toepasbaar is en, minstens zo belangrijk, wanneer niet. Als patterns meer 'mainstream' worden bij PHP zal daar hetzelfde probleem(?) ontstaan.

Hier staat ook iets hierover: http://jroller.com/page/ethdsy/20041221#oo_programmer_levels

[Verwijderd]

Deze discussie over OO zie je op elke van nature procedurele taal ontstaan. Wat men alleen eventjes moet begrijpen is dat OO eigenlijk een methodiek is om een bepaald resultaat te bereiken. Al ondersteund een taal niet volledig alle OO eisen, dan toch is het mogelijk om een produkt te ontwikkelen met een OO benadering. Als je doel bereikt is, en dat zijn meestal onderhoudbaarheid en uitbreidbaarheid, voorkomen van spaghetti code en overzichtelijkheid (ik mis hier nog wat), heb je het doel van OO bereikt.

Men hamert denk ik teveel op wat OO wel en wat OO niet moet kunnen. Als het dat niet kan dan is het niet voldoende. Maar men moet eens meer naar het resultaat kijken denk ik.

[Genoil]

Alarmnummer schreef op woensdag 22 december 2004 @ 18:26:

Zou je dit eens kunnen toelichten? Want ik zou niet weten wat voor betere oplossingen php heeft dan java/.NET for reuse.

Ik bedoel niet dat PHP betere oplossingen heeft voor reuse etc., maar deze mensen komen waarschijnlijk met een gedegen achtergrond in PHP4, een PHP5 server als doelplatform, hetgeen een relatief zware transitie naar Java of .NET met de enige reden het proper aanleren van OOP welhaast ridicuul maakt.

Dat weegt bij lange na niet op tegen de prima OOP implementatie van PHP5, waarvan je tegenwoordig ook niet echt meer kan zeggen dat het er maar tegenaan geplakt is (zoals in PHP4). Zend2 (de PHP5 engine) is een complete rewrite met het OOP idee in het achterhoofd.

Ik kan nu gewoon native PHP5 classes (zoals DOMDocument en Xsltprocessor) extenden, een DBAL als Propel/Creole inzetten en voor 90% de grote OOP hoed leegtoveren om een beter rendement te halen uit het werk dat ik doe.

Wel grappig dat je zegt dat 'jullie' ook C++ zouden moeten afbranden. Je wilt niet weten hoe ik met de beste bedoelingen C++ misbruikt heb. De enige reden waarom ik daar aan begon is omdat ik met Macromedia Director destijds geen dingen kon maken die snel genoeg waren voor de eisen die ik stelde aan de beelden die ik op het scherm wilde en omdat ik ergens had gehoord dat OOP 'cool' was. Ik had wel boek, maar het ging, zoals Gordijnstok ook opmerkt, vooral om het resulaat. Ik bedoel, ik lees dan zo af en toe het woord "Singleton" of "Patterns", en dan denk ik, "goh wat zou dat toch zijn, daar moet ik nog eens naar kijken.", maar het blijft voorlopig ver van m'n bed show...

Maar ik snap ook wel dat de wereld niet ophoudt bij website die een database weerspiegelen. Ik zeg ook niet dat PHP5 de hele markt gaat aanvreten

[ Voor 3% gewijzigd door Genoil op 22-12-2004 20:51 ]

[whoami]

Genoil schreef op woensdag 22 december 2004 @ 18:13:
Wat een onzin!

Jullie zitten daar gerieflijk met jullie fijn geconfigureerde IDEs, relatief excentrieke Tomcats/JBosses of wat dan ook en waarschijnlijk een pittige IT opleiding achter de kiezen te prediken dat je geen OOP moet leren met PHP5 maar met Java moet beginnen...realiseren jullie de overhead die dat geeft?

Nou, dan ga jij zeggen dat je evengoed OOP kunt leren door gebruik te maken van PHP, zonder een opleiding gevolgd te hebben, en dat je het evengoed zult kunnen door 'autodidactisch tewerk te gaan' (maw: prutsen en klooien tot het werkt), en dat je het evengoed zult kunnen als iemand die er wel een studie over gevolgd heeft?
Ik heb een IT studie gevolgd, ik ben daar in aanraking gekomen met OOP, ik heb daarna nog tientallen boeken gelezen over OO design, en dan nog voel ik me pas een beginneling.

Degenen daarvan die wat verder zijn zoeken veelal naar mogelijkheden om structuur, overzicht en herbruikbaarheid aan te brengen in hun werk. PHP5-OOP is daar zoveel meer geschikt voor dan Java!

Dit is je reinste onzin waar ik niet eens wens op in te gaan.

'wij autodidacten' inmiddels wel aan gewend (en het werkt wel ;)!)...bovendien geloof ik niet dat de betere PHP5 boeken/tutorials qua OOP-basics onderdoen voor hun Java equivalenten.

Dat is nu eens iets waar ik me aan erger: veel van de zogenaamde 'collega's' hebben die instelling: maar het werkt toch? Ja, het werkt, maar hoe? Hoe zit het met flexibiliteit, aanpasbaarheid, robuustheid?
Mensen met zo'n instelling zorgen ervoor dat de software-dev wereld een slecht imago krijgt.

Ik denk dat PHP5 de komende jaren zeker een stukje van de onderkant van de enterprise webapp markt gaat af snoepen waar J2EE en .NET nu nog domineren.

Ik denk niet dat er veel enterprise app's in PHP zullen geschreven worden.
Trouwens, waar je eind jaren '90 idd een verschuiving zag voor enterprise applications van client/server model naar web-model zie je nu weer meer een verschuiving van webapps naar smart client/rich UI applicaties. Dit omdat je zo een rijkere UI krijgt, en ook de voordelen van het 'no touch deployment' dat je met webapps hebt kunt verkrijgen.
Ik zie het niet zo direct mogelijk om in PHP een BL te bouwen die kan gebruikt worden door meerder UI's (web/Rich client/webservices...).

Nu zie je daar nog niet zoveel van omdat PHP5 nog niet eens een jaar oud is. Maar de laagdrempeligheid, de enorme PHP4 userbase en de concurerende performance geven PHP5 kans op (onverwacht) groot succes.

Ik vraag me serieus af hoeveel bedrijven er zullen zijn die hun kritieke (enterprise) applications zullen laten ontwikkelen op een platform dat veel eerder als hobby-project moet aanzien worden, dan als een serieus platform voor enterprise app's.

[Verwijderd]

whoami schreef op woensdag 22 december 2004 @ 21:02:
Dat is nu eens iets waar ik me aan erger: veel van de zogenaamde 'collega's' hebben die instelling: maar het werkt toch? Ja, het werkt, maar hoe? Hoe zit het met flexibiliteit, aanpasbaarheid, robuustheid?
Mensen met zo'n instelling zorgen ervoor dat de software-dev wereld een slecht imago krijgt.

OO code betekend niet per definitie dat je applicatie flexible, aanpasbaar en robuust is. Er zit nog een menselijke factor achter, en dat is de persoon die met behulp van OO een slechte architectuur opzet. Dan ben je net zo ver van huis.

Nu is het wel zo dat de kans dat een OO applicatie slecht is opgezet wel kleiner is dan met PHP, puur omdat de learning curve voor OO hoger ligt en je daarom gemiddeld een ander type programmeur hebt. Dat wil echter niet zeggen dat het probleem bij de taal ligt, het probleem ligt bij de kennis van een gebruiker en hoe hij deze toepast.

Een goed onderhoudbare, flexible en robuuste applicatie hangt meer af van de personen die het schrijven dan de taal, tenminste dat is mijn mening. Je hebt uitstekende programmeurs die sublieme architecturen kunnen opzetten met PHP die niet onderdoen voor Java, .NET implementaties, maar helaas zijn er gemiddeld gezien veel minder programmeurs met een gedegen kennis van architectuur die in PHP werken. Dat haalt in de discussie vind ik PHP onnodig naar beneden, daar het wel alle features heeft om dezelfde kwaliteit te halen als een applicatie in .NET of Java. Het ligt puur aan de persoon achter de knoppen.

Er zijn ook ervaren rotten in het vak die een pure OO taal als Java of .NET niet als hun preferente taal voor web development zien. Bijvoorbeeld Sean Corfield (www.corfield.org) is een ervaren ontwikkelaar die toch liever ColdFusion gebruikt als taal voor web development. Nu is ColdFusion van nature uit een procedurele interface gerichte taal, net als PHP, met een featureset die OO benaderd. Daaruit worden toch zeer sterke resultaten geboekt met alle doelen van OO zoals www.mach-ii.com.

[kvdveer]

whoami schreef op woensdag 22 december 2004 @ 21:02:
Ik vraag me serieus af hoeveel bedrijven er zullen zijn die hun kritieke (enterprise) applications zullen laten ontwikkelen op een platform dat veel eerder als hobby-project moet aanzien worden, dan als een serieus platform voor enterprise app's.

Zoals je het nu zegt lijkt je kritiek te zijn dat PHP te veel door hobbyisten wordt gebruikt.

Dat zou belachelijk zijn (daarom vermoed ik ook dat je dat niet bedoeld).

Ik ben zelf PHP-devver en ik heb wat ervaring met java. Wat mij voornamelijk opvalt aan als verschil tussen die twee is dat java tracht alles goed te doen¹ en dat PHP zo snel mogelijk tot resultaten lijkt te komen.

Als je PHP afkeurt omdat je er rotzooi in kunt maken ben je verkeerd bezig. Een typisch gevalletje kind&badwater. Je kunt in PHP netjes en overzichtelijk werken, in javastijl desnoods. Je kunt ook in tien statements een prutspagina in elkaar zetten.Veel autodydacten prutsen maar wat. Het is echter niet eerlijk om PHP hierop af te rekenen, ik werk zelf veel netter (denk ik).

Veel java-advocaten vergeten de term "right tool for the right job". Ik zal het niet in mijn hoofd halen om java te gaan gebruiken voor een kleine site die ik in zijn geheel kan overzien. De overhead (in programmeerwerk) in java is dan relatief veel te groot. Zoiets kun je vrij snel in PHP opzetten. Voor een grote site, met meer logica dan data is java waarschijnlijk een betere keus. Dat maakt niet een van de talen beter, ze hebben hun eigen toepassingsgebied.

nog een ander punt. Veel van de reacties in dit topic rekenen PHP af op de fouten die in versie vier zaten. Dat is natuurlijk niet eerlijk nu versie 5 uit is. Versie 5 heeft zo ongeveer alle OO mogelijkheden die in een WeakTyped language mogelijk zijn. (m.u.v. namespaces !@#%$%$).

offtopic:
¹Dat is natuurlijk logisch: Java was een reactie op de fouten in C. Java is dan ook een fout-voorkomende taal op veel punten. Dat blijkt uit de bemoeizuchtige compiler (NOFI), de sterke typering en andere zaken.

[Alarmnummer]

Alhoewel ik een leuk bashing topic wel erg prettig vind hoop ik dat dit topic niet weer gaat verzanden in een php/java bashing. Die hebben we vorige week net gehad en dan lopen we weer de zelfde argumenten te geven.. en dat is saai

[whoami]

Verwijderd schreef op woensdag 22 december 2004 @ 21:25:
[...]


OO code betekend niet per definitie dat je applicatie flexible, aanpasbaar en robuust is. Er zit nog een menselijke factor achter, en dat is de persoon die met behulp van OO een slechte architectuur opzet. Dan ben je net zo ver van huis.

Dat zeg ik niet, en daar heb je ook gelijk in.
Daarom is het belangrijk dat men op een goeie manier OOP onderwezen krijgt, en dat kan je niet alleen 'autodidactisch'.

Nu is het wel zo dat de kans dat een OO applicatie slecht is opgezet wel kleiner is dan met PHP, puur omdat de learning curve voor OO hoger ligt en je daarom gemiddeld een ander type programmeur hebt.

eens.

Dat wil echter niet zeggen dat het probleem bij de taal ligt, het probleem ligt bij de kennis van een gebruiker en hoe hij deze toepast.

Ook eens, maar als Genoil zegt dat hij als 'autodidactische hobbyist' evengoed het OO concept beheerst, dan ga ik daar tegen in.

Een goed onderhoudbare, flexible en robuuste applicatie hangt meer af van de personen die het schrijven dan de taal, tenminste dat is mijn mening.

Ik heb nooit gezegd dat bv. Java garant staat voor een goed opgezette / gedesigned applicatie.
Het is wel zo -zoals je zelf al gezegd hebt- dat de kans op een goed design bij opgeleide Java mensen hoger ligt dan bij hobbyende PHP'ers.

[Alarmnummer]

Ik denk dat veel van de Javahova`s (en andere gelovigen) voor hun studie ook veel aan het thuis prutsen zijn geweest en juist daardoor heel goed weten wat het is om te denken dat je iets begrijpt. Ik vond mezelf voor mijn studie ook al een geweldig begaafde programmeur maar als ik er nu aan terug denk ik ook.. van jezus.. wat een totale noob. Dus het is niet zozeer een kwestie van 'ik heb een opleiding gedaan dus ik ben slimmer dan jou', maar het is dat je echt een stuk bagage hebt opgedaan tijdens je studie en je goed weet dat je zonder 'studie' nergens bent. Onder studie hoeft om mij niet zozeer een groot gebouw met een hele lading nare/vervelende/domme mensen/leraren te vallen, maar dat kan ook thuis/zeflstudie zijn achter goeie (non reference) boeken waardoor je gewoon een groter overzicht krijgt. En als je eind taal als professional nu php/java/.net gaat worden zal voor een bepaalde types applicaties niet zo heel veel uitmaken.

Maar dat php niet geschik is om te leren programmeren ben ik het wel mee eens. Ik heb zelf lang basic en daarna c + beetje assembler geschreven en als je weet wat voor godsellendige troep ik daar mee heb gemaakt Nu kan ik er wel op een hele nette manier in werken als dat zou moeten... maar om een taal/concept goed te leren heb je gewoon goeie instrumenten nodig.

[ Voor 5% gewijzigd door Alarmnummer op 22-12-2004 21:58 ]

[Verwijderd]

Alarmnummer schreef op woensdag 22 december 2004 @ 18:32:
Dan hou jij er een hele vreemde optiek op na. Een goed ontwerp is zo simpel mogelijk.

Uhm, dat is mijn optiek.

Kijk eens naar de enorme collectie met java apen die je aantreft in de Agile stroming. Dus ik zou als ik jou was je mening even hierzien en in ieder geval geen genaraliserende uitspraken te doen.

Ik zou nu kunnen beginnen met ranten over buzzwords zoals "agile" cq. "extreme", maar dat is zo vermoeiend; persoonlijk heb ik me altijd verre gehouden van "stromingen" binnen een programmeertaal/design omdat die je juist verleiden tot zaken als overdesign of blinde vlekken kweken op bepaalde toepassingsgebieden.

In de praktijk kreeg ik (voor mijn ziekte) regelmatig te maken met stagiaires met een Java-achtergrond die niet in staat waren efficiente C++ te schrijven; en dan ging het niet over memory allocation en pointers maar om wat ik "misplaatste OO-esthetiek" noem, men produceerde code die niet anders dan als barok omschreven kan worden.

(Design by committee ellende weggeknipt, zijn we het roerend over eens.)

Check verder mijn signature over hoe ik denk over complexiteit en check mijn 'anti-complexiteit' replies.

Ik lurk heel wat P&W topics af, maak je geen zorgen. Ik vind het juist een teken aan de wand dat een overtuigd Javahova als jij er zo zijn levensmissie van maakt om de (over)complexiteit te bestrijden, volgens mij ben jij net zoveel barokke (Java) code tegengekomen als ik

Persoonlijk leg ik de schuld niet zozeer bij Java alswel bij de nadruk op het gebruik van patterns dat er tijdens het Java-onderwijs gelegd wordt. Ik kan begrijpen dat een complex designpattern voor een beginnend programmeur een "aha-erlebnis" kan zijn, maar als het "aha-erlebnis" in individuele gevallen (lees: middelmatige programmeurs) uitblijft wordt een pattern een houten been dat te pas en te onpas ergens onder gemonteerd wordt (want dan kiept het niet om).

[ Voor 3% gewijzigd door Verwijderd op 23-12-2004 02:12 ]

[Genoil]

whoami schreef op woensdag 22 december 2004 @ 21:02:
[...]

Nou, dan ga jij zeggen dat je evengoed OOP kunt leren door gebruik te maken van PHP, zonder een opleiding gevolgd te hebben, en dat je het evengoed zult kunnen door 'autodidactisch tewerk te gaan' (maw: prutsen en klooien tot het werkt), en dat je het evengoed zult kunnen als iemand die er wel een studie over gevolgd heeft?

Of ik dat ga zeggen? Nee dat ga ik niet zeggen . Ik probeer de boel hier alleen een beetje informatief te houden voor de meeste mensen die er mee aan de slag willen. Ik zeg niet dat ze daarmee eenzelfde resultaat zullen behalen als wanneer ze een gedegen opleiding (in Java) hadden genoten. De stap van klooien met PHP4 naar het betere werk is nou eenmaal gemakkelijker en praktischer door met PHP5 te gaan werken, en daar gaat dit topic volgens mij over.

Ik heb een IT studie gevolgd, ik ben daar in aanraking gekomen met OOP, ik heb daarna nog tientallen boeken gelezen over OO design, en dan nog voel ik me pas een beginneling.

Misschien zit hierin ook wel het verschil in onze mening. Ik kom van de kunstacademie en nu probeer ik vakwerk af te leveren in m'n (ons) eigen bedrijf. Ik sta er uberhaupt niet bij stil hoe ver ik ben qua kennis (en ik heb geen tijd voor boeken), ik leer gewoon door zodat ik m'n werk gewoon beter kan doen, klaar. Met PHP5 ben ik sneller en netter dan in PHP4 en ik zou compleet de plank mis slaan als ik me zou richten op Java. Ik denk dat meer mensen dat kunnen en daarvan profiteren en daarom probeer ik me sterk te maken tegen dat pietlullerige geouwehoer uit het Java-kamp over de zogenaamde "gevaren" van PHP5. Het gaat hier toch over mogelijkheden, niet over beperkingen?

Dat is nu eens iets waar ik me aan erger: veel van de zogenaamde 'collega's' hebben die instelling: maar het werkt toch? Ja, het werkt, maar hoe? Hoe zit het met flexibiliteit, aanpasbaarheid, robuustheid?
Mensen met zo'n instelling zorgen ervoor dat de software-dev wereld een slecht imago krijgt.

Mja daar stond een knipoog die niet echt lekker gerenderd werd maar je hapt er wel lekker in moet ik zeggen . Ik voel me ook helemaal geen onderdeel van de "software-dev wereld"...er zijn vast mensen die zich daartoe voelen behoren en als zodanig een bepaalde verantwoordelijkheid voelen wat betreft de uitdraging van hun vak en dat mag ook allemaal wel, maar er zijn ook mensen die kleinschaliger bezig zijn, dichter bij de markt opereren en daardoor veel meer gericht zijn op resultaat.

[...]

Ik denk niet dat er veel enterprise app's in PHP zullen geschreven worden.
Trouwens, waar je eind jaren '90 idd een verschuiving zag voor enterprise applications van client/server model naar web-model zie je nu weer meer een verschuiving van webapps naar smart client/rich UI applicaties. Dit omdat je zo een rijkere UI krijgt, en ook de voordelen van het 'no touch deployment' dat je met webapps hebt kunt verkrijgen.
Ik zie het niet zo direct mogelijk om in PHP een BL te bouwen die kan gebruikt worden door meerder UI's (web/Rich client/webservices...).


[...]

Ik vraag me serieus af hoeveel bedrijven er zullen zijn die hun kritieke (enterprise) applications zullen laten ontwikkelen op een platform dat veel eerder als hobby-project moet aanzien worden, dan als een serieus platform voor enterprise app's.

Misschien moet ik het anders verwoorden. Ik denk dat PHP5 drempelverlagend werkt als instap op het serieuzere werk. Denk je nou dat ik probeer interessant te doen door te zeggen dat ik mijn nieuwe bling bling PHP5 classes kan extenden van native classes en dat er een gerse DBAL beschikbaar is? Nee! Ik probeer te zeggen "Hee mensen PHP5 is relaxed en je kunt er leuke dingen mee doen, kijk hier etc". Het is gewoon een beetje tegengas tegen dat geziek over of die frikkin OOP implementatie wel of niet educatief verantwoord is. PHP5 heeft veel meer de mogelijkheid de acceptatie van OOP in de wat minder complexe regionen van het toepassingspectrum te vergroten dan Java, en komt daarmee op een hoger plan( tov PHP4), terwijl de "onderkant van de markt" nog net zo goed behouden blijft.

Ook eens, maar als Genoil zegt dat hij als 'autodidactische hobbyist' evengoed het OO concept beheerst, dan ga ik daar tegen in.

Ja wederom dat zeg ik dus helemaal niet, ik doelde slechts op de doelgroep van dit forum en ik heb nergens gezegd dat ik een evengoede kennis van OOP heb als wie dan ook. Ik heb er slechts kennis van, die pas ik met genogen toe en ik vind het leuk om die ook met anderen te delen.

[Verwijderd]

Ongeacht je opleiding of -zelf-studie, uiteindelijk zijn je programmeerkunsten gebaseerd op 'trail & error'. Het enige verschil is dat vanuit een (goede) opleiding begrippen -concepten- en definities veel duidelijker zijn.

Maar waar leer je nou werkelijk programmeren? Bij die relatief kleine projecten die je maakt voor opleiding of bij een volledige applicatie maken binnen een bedrijf? Het antwoord lijkt me logisch...

Overigens zul je sommige tech columnisten en amerikaanse sites al vrolijk J2EE als 'opgeblazen' zien afdoen tov .NET (en dan met name ASP.NET). Functioneel gezien heb je voor een relatief simpele site helemaal geen extreme OO taal nodig zoals J2EE en kun je volstaan met asp en php. Daar zijn ze toch ook voor gemaakt? (toch?)

Ik denk trouwens dat het 'ik ben een programmeer noob' altijd wel zal blijven bij de nieuwere programmeurs. Stel je voor dat je al die miljoenen regels code uit je kop zou kunnen knallen en elk in en uitje op haast assembler niveau zou kunnen uitleggen...:/
* noob zijn kan soms ook verlossend zijn *

[Alarmnummer]

Verwijderd schreef op donderdag 23 december 2004 @ 16:20:
Ongeacht je opleiding of -zelf-studie, uiteindelijk zijn je programmeerkunsten gebaseerd op 'trail & error'.

Mee eens.. Je moet dingen in de praktijk proberen om het echt te begrijpen. Vanuit een studie krijg je wel een goed overzicht, maar je moet echt praktische ervaring ermee hebben om het goed onder de knie te krijgen.

Het enige verschil is dat vanuit een (goede) opleiding begrippen -concepten- en definities veel duidelijker zijn.

Hmm tja.. Vanuit een opleiding krijg je ook inzichten die je in de praktijk niet zo snel zou opdoen. (Ik spreek uit ervaring).

Maar waar leer je nou werkelijk programmeren? Bij die relatief kleine projecten die je maakt voor opleiding of bij een volledige applicatie maken binnen een bedrijf? Het antwoord lijkt me logisch...

Geen eerlijke vergelijking. Jij zegt dat je dus niets leert vanuit de theorie want jij stelt schoolprojecten tegenover de praktijk en dat is geen vergelijking.

Overigens zul je sommige tech columnisten en amerikaanse sites al vrolijk J2EE als 'opgeblazen' zien afdoen tov .NET (en dan met name ASP.NET). Functioneel gezien heb je voor een relatief simpele site helemaal geen extreme OO taal nodig zoals J2EE en kun je volstaan met asp en php. Daar zijn ze toch ook voor gemaakt? (toch?)

Volgens mij spreek jij over iets waar je geen verstand van hebt. J2EE = geen oo taal. J2EE = een rits met gerelateerde serverside technieken voor het Java platform.

Ik denk trouwens dat het 'ik ben een programmeer noob' altijd wel zal blijven bij de nieuwere programmeurs.

Ja maar wat wil je hiermee zeggen?

Stel je voor dat je al die miljoenen regels code uit je kop zou kunnen knallen en elk in en uitje op haast assembler niveau zou kunnen uitleggen...:/

Hmmm.. denken op dit nivo is zo.. noobs... Ik wil juist niets meer hoeven uit te leggen op het lage nivo. Dat interesseerd me echt niets. Ik wil een omgeving die de vele nare problematiek voor me oplost zodat ik me alleen nog maar hoef te concentreren op de core problematiek ipv al die ellendige boilerplate code.

* noob zijn kan soms ook verlossend zijn *

Ja... daarom zijn kinderen bv ook zo onbezorgd en gelukkig. Helaas moet je wel volwassen worden als je op volwassen nivo software wilt ontwikkelen.

[Verwijderd]

Alarmnummer, ik ben benieuwd of jij wel eens grote sites hebt ontwikkeld in een niet OO taal zoals asp, php, coldfusion? Je houdt er voor mijn gevoel een enorm pro OO standpunt en een enorm negatief niet OO standpunt op na

Vervolgens spreek je over "Ja... daarom zijn kinderen bv ook zo onbezorgd en gelukkig. Helaas moet je wel volwassen worden als je op volwassen nivo software wilt ontwikkelen." waarmee je eigenlijk aangeeft, als je niet in OO bezig bent ben je niet op een volwassen niveau bezig met ontwikkelen. Sla je hier nu niet de plank mis? Is het immers niet belangrijker, en volwassener om te kijken naar het eindresultaat dan de gebruikte technieken?

Er draaien enorme websites op niet OO talen, die onderhoudbaar zijn, schaalbaar, rocksolid draaien en zijn in een veel korter tijdsbestek gerealiseerd dan een gemiddelde applicatie met een pure OO taal voor elkaar zou krijgen. Het zijn websites die enorme bezoekersaantallen voor hun kiezen krijgen, zeer divers zijn, op meerdere servers draaien. Een voorbeeld van zo'n applicatie gebruik je nu, namelijk dit forum. Zou het volgens jou beter zijn geworden als het in een OO taal was gemaakt, zoja waarom?

[Alarmnummer]

Verwijderd schreef op donderdag 23 december 2004 @ 19:43:
Alarmnummer, ik ben benieuwd of jij wel eens grote sites hebt ontwikkeld in een niet OO taal zoals asp, php, coldfusion? Je houdt er voor mijn gevoel een enorm pro OO standpunt en een enorm negatief niet OO standpunt op na

Nee hoor.. De huidige aanpak van Java met al zijn overgecompliceerde configuraties opties waarvan je maar een fractie gebruikt, je totaal verzand in de configuratie xml hel en weet ik veel wat nog meer maakt mij zeker geen tevreden java-weblayer developer.

Ik zit wel vaak aan de achterkant en dan ben ik wel uitermate tevreden met Java en alle mogelijkheden die het mij biedt. Zeker doordat er zulke extreem geavanceerde ide`s beschikbaar zijn met code completion, syntax checking, error suggest fix, refactoring support. En verder ook doordat java (en .net/c++) erg krachtige type systemen hebben waarmee ik alleen de code al een enorm stuk informatiever vind (en het is dan nog eens fijn dat de compiler het ook nog een kan checken).

waarmee je eigenlijk aangeeft, als je niet in OO bezig bent ben je niet op een volwassen niveau bezig met ontwikkelen. Sla je hier nu niet de plank mis? Is het immers niet belangrijker, en volwassener om te kijken naar het eindresultaat dan de gebruikte technieken?

Ben ik helemaal mee eens. En misschien dat jullie minder fouten maken dan ik, maar ik maak ze bij de vleet en daarom ben ik blij dat ik wat assistentie krijg van een IDE/Compiler/Unit testen zodat ik in iedergeval de grootste collectie eruit kan pakken.

Er draaien enorme websites op niet OO talen, die onderhoudbaar zijn, schaalbaar, rocksolid draaien en zijn in een veel korter tijdsbestek gerealiseerd dan een gemiddelde applicatie met een pure OO taal voor elkaar zou krijgen. Het zijn websites die enorme bezoekersaantallen voor hun kiezen krijgen, zeer divers zijn, op meerdere servers draaien. Een voorbeeld van zo'n applicatie gebruik je nu, namelijk dit forum. Zou het volgens jou beter zijn geworden als het in een OO taal was gemaakt, zoja waarom?

Ik betwijfel of het veel beter zou zijn geworden. Maar het hangt ten 1e af van het soort applicatie wat je maakt. Voor sommige zaken met lastige threading problematiek, complexe transacties en weet ik veel wat nog meer kijk ik gewoon liever naar een gedegen taal waar ik veel mensen/ideeen/frameworks kan vinden waar ik mezelf wel goed in kan vinden en waarvan ik weet dat ik er ook een tijd mee vooruit kan ipv meteen aan de max te zitten.

Ik wil Java zeker niet de hemel in prijzen want er zit genoeg vuiligheid in die je in tranen kan doen uitbarsten. Maar ik programmeer al een tijdje (gok intussen al een jaar of 10) en ik ben iedere keer blij als ik een omgeving kan vinden die mij zoveel mogelijk kan helpen om fouten op te sporen, en mijn gedachten en creativiteit kan helpt uiten.

* Alarmnummer = bv ook redelijke Prolog (declaratief) waar ik ook al wat functionele extensies heb toegevoegd Dus ik hou van verschillende paradigma`s en oo is echt niet je van het.

Maar ik zie de toegevoegde waarde niet in van script omgevingen Ik durf te wedden dat ik sneller kan programmeren dan een php`er die net zo snel kan werken als ik en we beschikking zouden hebben over dezelfde libraries. Ten 1e zijn er dus extreem goeie ide`s beschikbaar en ten 2e hoef ik minder lang te debuggen.

[edit]
Ik zie trouwens dat je ASP er ook hebt staan. Maar sorry.. ASP is volslagen crap. Echt de grootste hoop ellende die ik ooit heb durven aanschouwen. (En voor de duidelijkheid.. ik werk op dit moment met ASP.NET (en das wel cool)).

[ Voor 20% gewijzigd door Alarmnummer op 23-12-2004 20:05 ]