[alg] OO/polyformisme in talen (oa php)

[ACM]

OO werken in php zonder polymorphisme?

Kwam ik vanmiddag in een discussie tegen hier op GoT.
Het was een antwoord/vraag op een suggestie van mij dat je in php best OO kan programmeren
Natuurlijk was die suggestie een beetje uitlokkend bedoeld (als men ontkent/bevestigd dat iets kan, moeten ze het ook aannemelijk kunnen maken imho), maar wel degelijk op de waarheid gebaseerd.

In php kan je gewoon (ok, niet zo gewoon als in java) OOP toepassen.
De opmerking hierboven doet denken dat PHP er hopeloos ongeschikt voor is, want er zou geen polymorfisme in php zijn.
Nou vond ik dat een beetje een vreemde/foute suggestie en ben ik es beter gaan navragen/zoeken wat er onder polymorfisme wordt verstaan.
mbravenboer gaf mij dit terug in een mailtje:

Luca Cardelli heeft in het zeer bekende artikel "On Understanding Types,
Data Abstraction, and Polymorphism" een kwalificering gemaakt van
polymorphisme:

1) Universal polymorphism:
a) Parametrisch
b) Inclusion

2) Ad hoc polymorphism
a) Overloading
b) Coercion

Overloading en coercion worden hierbij over het algemeen als de minder
interessante vormen van polymporphisme gezien, maar zijn daarom niet
minder nuttig. Het belangrijkste verschil is dat bij ad hoc
polymporphisme er meestal _verschillende_ implementaties zijn voor de
verschillende situaties en ook een _eindig_ aantal situaties, terwijl er
bij universal polymorphisme maar 1 implementatie is voor _alle_
verschillende situaties.

Overloading zie je vrijwel in alle getypeerde talen, bijvoorbeeld door
de + operator op zowel floats als ints als strings, of bijvoorbeeld door
overloading van methode namen. Bij coercion worden types automatisch
geconverteerd naar een type waarop de operatie kan worden uitgevoerd.
Ook dit zie je in erg veel talen en waarschijnlijk in het bijzonder in PHP.

Met inclusion polymorphisme gaat het om subtyping met super- en
subklassen. Hierdoor behoort een object dus tot verschillende typen en
daardoor kan je wellicht op verschillende typen dezelfde operaties
uitvoeren als deze objecten ook tot een andere gezamelijk type behoren.

Bij parametrisch polymorphisme is een methode of klasse
geparameterizeerd met een type variabele. De code van de methode of
klasse kan functioneren voor alle waarden van deze variabele. Eventueel
moet dus paramter voldoen aan bepaalde constraints.

Als je dus echt een goed oordeel wilt vormen moet je gewoon langsgaan of
de verschillende vormen van polymorphisme worden ondersteunt. Als je
zegt dat PHP geen polymorphisme kent zeg je in feite dat alle vormen
niet worden ondersteunt en dat is denk ik een wat kansloze uitspraak.
Waarschijnlijk wordt er dus bedoeld dat de interessantere vormen
(universal polymorphisme) niet worden ondersteunt.

En even stuk voor stuk aflopen. Parametrisch polymorfisme is kent men van generics, inclusion kent men van inheritance.

4 vormen dus, afgebeeld op php:
coercion is simpel, mbravenboer zegt het ook al, tegenwoordig heeft bijna elke taal dat wel (bij 1 + 1.5 wordt vaak al coercion toegepast, de float wordt omgezet in een int).
overloading, ook dat kent php, simpelweg omdat er + overloading is Niet zo uitgebreid als in c++, maar dat kan java ook niet. Methode overloading is er deels, je kan (helaas) niet meerdere keren dezelfde methode met verschillende typen en hoeveelheden parameters aanroepen (tenminste, niet met verschillende methodes, wel dezelfde methode, maar das geen overloading).
Wel kan je methoden van superclassen overloaden/herdefinieren.
inheritance, overerving, dat kent php zeker. Hoewel er geen echte structuur is en er geen erving tot een of ander root-object is, php kent wel degelijk overerving.
parametrisch, generics, heel flauw... Je _zou_ kunnen zeggen dat zelfs dit tot op zekere hoogte kan in php Er is tenslotte geen/nauwelijks (expliciete) typering, dus kan je een formule/functie net zo makkelijk met ints als floats laten werken, zonder er een tweede versie van te moeten schrijven. In principe heb je dus een generieke functie. Het is wat lastiger dat je er geen beperkingen op kan leggen, dus je zou ook een object-array in een sorteer- of max-algoritme kunnen proberen te stoppen, die bedoeld is voor getallen...

Goed nou is het leuk dat ik van elke vorm van polyformisme een voorbeeld kan bedenken. Maar het gaat me er eigenlijk meer om, dat ik een helderder beeld wil krijgen van wat men nou nodig vindt voor OOP en uiteraard kan ik dan als een flauw rode draad proberen te bewijzen dat PHP OOP toegepast kan worden

Het blijkt wel uit de acceptatie van Java dat primitieven niet zo erg gevonden wordt, ook al is dat niet helemaal object oriented.
Dus de notie "alles is een object" is al niet per se noodzakelijk. Natuurlijk wel "zo veel mogelijk moet een object zijn" (en hier gaat php de fout in wat OO betreft natuurlijk OB kan nog prima).
"Knoeien met het type systeem" is een noodzaak voor OOP (polyformisme, eventueel subtyping, etc)
En er moet natuurlijk een notie zijn van objecten/etc, niet zo als php de mogelijkheid voor objecten. Want eigenlijk is php niet OO, maar je _kan_ er OB in programmeren en als je voor alles wrapper classen schrijft/gebruikt kan je zelfs (imho) OO ermee werken.

Kom maar op, wat vind je nodig voor je iets OOP wil noemen? (en eventueel mag je ook commentaar leveren op de rest van het relaas )
Gelijk nog een leuke nadenker, wat vind je van het gebruik van Arrays en dat soort lowlevel constructs in OO (die in php is trouwens best highlevel, het is een multifunctioneel ding dat je als een map, list(?), stack, queue en array kan gebruiken)?

[Nielsz]

Redelijk offtopic:
Je ging uitzoeken wat Poly... was.. Dan baseer je je meestal op meer dan 1 bron, zelfs al is het Martin

[ACM]

Nielsz schreef op 19 November 2002 @ 22:26:
Redelijk offtopic:
Je ging uitzoeken wat Poly... was.. Dan baseer je je meestal op meer dan 1 bron, zelfs al is het Martin

Klopt, collegesheets van mijn docent OO gaven hetzelfde weer als Martin. Glimi wist er ook weinig anders over te zeggen. En ik herinner me nog wel iets van een 2e jaars college over programmeertalen in zijn algemeenheid
Ik vond het niet nodig om nog meer bronnen te raadplegen... En trouwens, volgens mij is dit forum ook een prima bron van informatie
Als het fout is ergens, verbeter het dan!

[Alarmnummer]

Voor oo polymorfisme wordt inclusion (overerving) polymorfisme bedoelt: het runtime uitzoeken welke methode definitie op een object uitgevoerd moet worden Dus een single dispatch op het impliciete 1e argument.

[xerix]

Er zijn 3 fundamentele eigenschappen die een OO taal moet hebben, information hiding, inheritence en polymorphisme. Ik weet niet in hoevere PHP hier aan voldoet. Volgens mij zou je wel aan deze eigenschappen kunnen voldoen hetzij via ranzige hacks/methoden.
Maargoed, ik vind PHP dan ook een peppie en kokkie _scripttaal.

[Alarmnummer]

PHP heeft wel encapsulation, maar geeft geen foutmelding als je iets doet wat niet mag (althans dat was de stand van zaken een tijdje geleden).

Maargoed, ik vind PHP dan ook een peppie en kokkie scripttaal.

flame !!

[ACM]

[nohtml]

xerix schreef op 19 november 2002 @ 22:45:
information hiding

Doet ie prima. Dat de implementatie niet helemaal voldoende is is wat anders. Je kan geen public/private/etc aangeven, maar dat het basisprincipe van informationhiding kan prima met de php-classes zoals ze in de zend1 engine beschikbaar zijn.

, inheritence en polymorphisme. Ik weet niet in hoevere PHP hier aan voldoet.

Zie hierboven, openingspost.

Volgens mij zou je wel aan deze eigenschappen kunnen voldoen hetzij via ranzige hacks/methoden.

Nee, dit zijn dingen die out-of-the-box al redelijk tot goed werken

Hoe het intern geregeld is in de php-engine wil ik niet weten, maar dat wil ik van Java/C#/C++ etc ook niet weten.

[xerix]

ACM schreef op 19 November 2002 @ 22:56:
[nohtml]
[...]

Nee, dit zijn dingen die out-of-the-box al redelijk tot goed werken

Redelijk tot goed?

Alarmnummer schreef op 19 November 2002 @ 22:48:
[...]

flame !!

Ja nou... ja De taal opzich is best leuk om redelijk snel een dynamische webpagina op te zetten, maar vaak wordt door php programmeurs (?) het doel van de taal over het hoofd gezien.

[ACM]

xerix schreef op 19 November 2002 @ 23:06:
Redelijk tot goed?

Als ik zeg dat het perfect werkt lieg ik gewoon.
Bij data hiding missen de private/public/etc, die de data hiding nog wat beter afdwingt en reguleerd.
Bij overloading mist het kunnen overloaden van dezelfde methode binnen een class.
Bij overerving zou je kunnen zeggen dat een rootobject mist (maar of dat een gemis is weet ik niet?)

Ja nou... ja De taal opzich is best leuk om redelijk snel een dynamische webpagina op te zetten, maar vaak wordt door php programmeurs (?) het doel van de taal over het hoofd gezien.

Het doel wijzigt ook langzamerhand, dat maakt het nog wat vervelender
De support van Zend was een aardig stap in een goeie richting, hopelijk wordt Zend2 een serieuse stap in de OO richting (en sowieso een weer een nieuwe grote stap naar uniformiteit, logica en stabiliteit) en dat mag dan best op een C++ manier hybride zijn.

[^Mo^]

ACM schreef op 19 November 2002 @ 23:22:

[...]
Als ik zeg dat het perfect werkt lieg ik gewoon.
Bij data hiding missen de private/public/etc, die de data hiding nog wat beter afdwingt en reguleerd.
Bij overloading mist het kunnen overloaden van dezelfde methode binnen een class.
Bij overerving zou je kunnen zeggen dat een rootobject mist (maar of dat een gemis is weet ik niet?)

[...]

Het doel wijzigt ook langzamerhand, dat maakt het nog wat vervelender
De support van Zend was een aardig stap in een goeie richting, hopelijk wordt Zend2 een serieuse stap in de OO richting (en sowieso een weer een nieuwe grote stap naar uniformiteit, logica en stabiliteit) en dat mag dan best op een C++ manier hybride zijn.

Er werd mij laatst hier ergens op GoT (kan ook wel T.net frontpage zijn) verteld dat het juist meer Java-achtig werd. Dus per file een class maken, nou ja, 'tis bekend hoe het werkt
Wellicht dat JSP op die manier wat meer kan concurreren...

[kvdveer]

De Zend2 engine gaat het volgende introduceren:
1. We werken niet meer met objecten, maar standaard met referenties daaraan.
2. Hierdoor werkt het retourneren van niet nieuw gemaakte objecten eindelijk goed.
3. Een __clone() method, overloadbaar
4. Destructors.
5. Delete statement

Over de volgende zaken wordt nog na gedacht:
1. Multiple inheritance... (Bereid je maar vast voor op de topics daarover)
2. Acces regulation: public en private (== protected)
3. Static class members (alleen vars, methods konden al)
4. Exception handling (laten we het hopen)
5. Overloadbare Objecten aangeboden vanuit modules/plugins. (hmm deja-vu: $forum = new forum())
6. Veranderde 'per-character' stringtoegang.

Zoals je ziet hebben de meeste zaken die worden veranderd met de oo engine van PHP te maken. Vol verwachting klopt mijn hart!

edit:
Onduidelijkgeden weggewerkt... Bedankt .oisyn

[kvdveer]

kvdveer schreef op 19 November 2002 @ 23:50:
1. We werken niet meer met objecten, maar standaard met referenties daaraan.
2. Hierdoor werkt het retourneren van niet nieuw gemaakte objecten eindelijk goed.

Even om te laten zien waarom het nu niet werkt:

PHP:

$blaat=0;

function foo() { 
  return new Bar();
}

class Bar {
  var member;
  function Bar() {
    global $blaat;
    $blaat = &this;
  }
}

$a = foo();
$a->member = 10;
if($a->member != $blaat->member) {
  die("a horrible death");
}

Zoek de bug... (de oplossing is: $a =&foo())

edit:
onbedoelde bug fixed

[ACM]

[nohtml]

kvdveer schreef op 19 November 2002 @ 23:50:
De Zend2 engine gaat het volgende introduceren:
1. We werken niet meer met objecten, maar standaard met referenties daaraan.
2. Hierdoor werkt het retourneren van niet nieuw gemaakte objecten eindelijk goed.

*zwijmel*

5. Delete statement

Hopelijk krijg je ook je geheugen dan terug

Over de volgende zaken wordt nog na gedacht:
1. Multiple inheritance... (Bereid je maar vast voor op de topics daarover)

Liever niet eigenlijk... Doe dan een variant van interface-ondersteuning.

6. Veranderde 'per-character' stringtoegang.

Kon dat nog niet
Of anders dan nu, bedoel je?

[vinnux]

Primitieve datatype zijn niet OO en dat moet zo maar blijven hoofdzakelijk vanwege het performence verlies bij het gebruik van een object. Toch kan het verschil tussen primitieve datatypes en objecten nogal een voor verwarring zorgen, zoals bijvoorbeeld in de taal Java. Bij objecten wordt alles bij reference door gegeven en bij primitieve datatype, behalve arrays, by value.
Dit kan zeker tot moeilijkheden leiden bij het leren van deze taal, maar daar gaat het hier niet over.

Het gebruik van primitieve datatypes is gewoon iets wat je er waarschijnlijk gewoon niet meer uitkrijgt al zou je het willen

Ja wanneer is een taal OO. Moeilijke vraag, zeker als je bedenkt dat een taal altijd in een andere taal geschreven is, wat weer betekend dat de nieuwste taal een specificatie is van de oude taal. In die trent kun je zeggen dat de taal waar het in geschreven OO al moet ondersteunen en is hiermee machine taal OO.

Om goed te beoordelen of een taal OO is moet je vooral kijken denk ik naar de zaken die NIET mogelijk zijn ipv zaken die WEL mogelijk zijn.

[.oisyn]

kvdveer schreef op 19 November 2002 @ 23:56:
[...]


Even om te laten zien waarom het nu niet werkt:

PHP:

$blaat=0;

function foo() { 
  return new Bar();
}

class Bar {
  var member;
  function Bar() {
    global $blaat;
    $blaat = &this;
  }
}

$a = foo();
$a->member = 10;
if($a->member != $dezeBlaat->member) {
  die("a horrible death");
}

Zoek de bug... (de oplossing is: $a =&foo())

de bug is dat je in de class $blaat gebruikt, en in de if $dezeBlaat

[.oisyn]

ACM schreef op 20 November 2002 @ 00:12:
Liever niet eigenlijk... Doe dan een variant van interface-ondersteuning.
Of anders dan nu, bedoel je?

wat is er tegen multiple inheritance, vanuit developers standpunt gezien? (vanuit taal-implementeerders kan ik me er nog wel wat bij voorstellen, maar daar heb jij in principe niets mee te maken)

[kvdveer]

ACM schreef op 20 November 2002 @ 00:12:
[...]
Kon dat nog niet
Of anders dan nu, bedoel je?

Gewijzigd houdt in anders dan nu: Momenteel wordt een string behandeld als een array van karakters. Op zich is dat natuurlijk correct, maar het kon onduidelijkheden inhouden. De syntax wordt nu: $string{3} = 'a'. Ik vind dit persoonlijk trouwens nog ranziger dan de vorige oplossing...

[.oisyn]

vgouw schreef op 20 November 2002 @ 00:16:
Primitieve datatype zijn niet OO en dat moet zo maar blijven hoofdzakelijk vanwege het performence verlies bij het gebruik van een object.

onzin, waarom is bijvoorbeeld een int geen object? Dat het in een taal zoals java anders is is omdat een primitief by value en een object by reference werkt, maar wat is verder nou het wezenlijke verschil?

[kvdveer]

Nog even een on-topic post om weer eens wat nuttigs bij te dragen hier:

PHP heeft een object-georienteerde mogelijkheid, en met ZEND2 wordt het allemaal nog mooier.
Wat mij betreft missen er nog een aantal zaken om het perfect te noemen:
1. Facultatieve strong typing, zoals bij VBA. Alles is standaard een variant (juggling) tenzij je het anders pecificeerd.
2. Goede beschikbare objecten (begin nu niet over PEAR, want dat is toch een verzameling ranzige hacks om de tekortkomingen van PHP's OO engine op te heffen)
3. Abstract methods. (is wel te doen: een functie te implementeren met alleen een foutmelding)
4. Method overloading (strong typing vereist)
5. Interfaces
6. Verdere scheiding tussen runtime en 'compiletime'

[ACM]

.oisyn schreef op 20 november 2002 @ 00:18:
wat is er tegen multiple inheritance, vanuit developers standpunt gezien? (vanuit taal-implementeerders kan ik me er nog wel wat bij voorstellen, maar daar heb jij in principe niets mee te maken)

Wat gebeurd er bij:

PHP:

class super1
{
    function hello(){echo 'super1';}
}
class super 2
{
   function hello() {echo 'super2';}
}
class sub extends super1, super2
{
}

$sub = new sub();
$sub->hello();

En in dit simpele voorbeeld is het met overriding zo te voorkomen, maar als je wat grotere hierarchien hebt zie je het niet altijd aankomen. (je kan de compiler laten waarschuwen, maar is dat zo netjes?)

[killercow]

kvdveer schreef op 20 November 2002 @ 00:21:
[...]

Gewijzigd houdt in anders dan nu: Momenteel wordt een string behandeld als een array van karakters. Op zich is dat natuurlijk correct, maar het kon onduidelijkheden inhouden. De syntax wordt nu: $string{3} = 'a'. Ik vind dit persoonlijk trouwens nog ranziger dan de vorige oplossing...

ik snap niet waarom dit gedaan is, php draait op c++ ruimt,smaakt en handelt op string gebied als c++ dus dan is een array erg consitent met c++.

een string is in c niet meer dan een array van char objecten welke je vaak ook zo moest declareren en vullen, dat c++ het makkenlijker heeft gemaakt om daar een string object voor te hebben en deze alsnog als array te behandelen wil ng niet zeggen dat het in php dan maar geen array meer moet zijn, volgens mij dan.

ik vind die hele oplossing met {} eigenlijk ranzig en inconsistent, heb hem nog nooit nodig gehad en zal hem ook niet gebruiken. ook het ophalen van waarden uit multi-level arrays met $array[1][2] vind ik onlogisch en vaag maar jah.

[kvdveer]

.oisyn schreef op 20 november 2002 @ 00:23:

[...]


onzin, waarom is bijvoorbeeld een int geen object? Dat het in een taal zoals java anders is is omdat een primitief by value en een object by reference werkt, maar wat is verder nou het wezenlijke verschil?

Mee eens. Op compile-time moet een Integer wat mij betreft een object zijn, op runtime maakt het me geen donder uit, dat zoekt de compiler/runtimeenv maar weer uit.
Ik ben van mening dat deze code moet kunnen:

code:

int a = 4;
output(a->toString());

De runtime die is verantwoordelijk voor de performance van datastructuren, niet ik.

Als ik dan toch aan het ranten ben liefst zie ik dan de volgende overerving-tree:

code:

Object
+ Number (abstract: + - * / > < ==)
| + FloatingPointNumber (abstract: round floor ceil)
| | + Float
| | + Double
| | + bigfloat
| + IntegerNumber (abstract: % & | ^)
|   + int
|   + long
|   + bigint
+ Textual (abstract +)
| + char
| + String
+ bool (nee, een boolean is geen getal)

[ACM]

killercow schreef op 20 november 2002 @ 00:38:
een string is in c niet meer dan een array van char objecten welke je vaak ook zo moest declareren en vullen, dat c++ het makkenlijker heeft gemaakt om daar een string object voor te hebben en deze alsnog als array te behandelen wil ng niet zeggen dat het in php dan maar geen array meer moet zijn, volgens mij dan.

Mee eens, sterker nog. Zelfs als ze meer op Java ipv C++ willen lijken moeten ze er een array van chars van maken

ook het ophalen van waarden uit multi-level arrays met $array[1][2] vind ik onlogisch en vaag maar jah.

Waarom is dat onlogisch
Zo gebeurt het in elke C-like taal die ik ken.

[kvdveer]

ACM schreef op 20 November 2002 @ 00:37:
En in dit simpele voorbeeld is het met overriding zo te voorkomen, maar als je wat grotere hierarchien hebt zie je het niet altijd aankomen. (je kan de compiler laten waarschuwen, maar is dat zo netjes?)

Je kunt de compiler niet laten waarschuwen: Een deel kan gebeuren op runtime...

[ACM]

kvdveer schreef op 20 November 2002 @ 00:40:
Mee eens. Op compile-time moet een Integer wat mij betreft een object zijn, op runtime maakt het me geen donder uit, dat zoekt de compiler/runtimeenv maar weer uit.

Als php dat soort beslissingen ook nog moet maken @runtime/"na compilatie" dan zou het eigenlijk ook een compiled (on demand of JIT achtig) taal moeten worden met de functionaliteit van de zend accelerator geintegreerd (gecompileerde classen/files in het geheugen houden)

[.oisyn]

ACM schreef op 20 november 2002 @ 00:37:
[nohtml]
[...]
[/nohtml]
Wat gebeurd er bij:

PHP:

class super1
{
    function hello(){echo 'super1';}
}
class super 2
{
   function hello() {echo 'super2';}
}
class sub extends super1, super2
{
}

$sub = new sub();
$sub->hello();

compiler error

En in dit simpele voorbeeld is het met overriding zo te voorkomen, maar als je wat grotere hierarchien hebt zie je het niet altijd aankomen.

Om daarom maar gelijk een hele feature niet te ondersteunen, dus in het geval dat er weleens meerdere base classes met dezelfde members zouden kunnen zijn, vind ik een beetje onzin

(je kan de compiler laten waarschuwen, maar is dat zo netjes?)

ja, natuurlijk is dat netjes, er is namelijk ambiguiteit. Je zult de member expliciet op moeten geven. In C++ gaat dat zo:

C++:

Sub * sub = new Sub ();
sub->super1::hello ();
sub->super2::hello ();

geen probleem waar je niet omheen komt dus

[killercow]

jah das waar acm maar is het niet een beetje onlogisch? je wil toch een sub array aanspreken in een bepaalde opsitie in een array?

het is mischien wel logisch / makkenlijker om het met [1][2] te defineren en uit te lezen maar ik zou het eigenlijk zo willen hebben (logisch gezien dan) $array[1[2]] je wilt dus het object in hokje 2 van de array die in hokje 1 van $array zit hebben. ik weet niet, lijkt mij logischer.

[.oisyn]

kvdveer schreef op 20 November 2002 @ 00:40:
[...]


Mee eens. Op compile-time moet een Integer wat mij betreft een object zijn, op runtime maakt het me geen donder uit, dat zoekt de compiler/runtimeenv maar weer uit.

dat is niet wat ik bedoelde, ik zal zo uitleggen waarom

Ik ben van mening dat deze code moet kunnen:

code:

int a = 4;
output(a->toString());

De runtime die is verantwoordelijk voor de performance van datastructuren, niet ik.

Dat kan alleen als elk object per se overerft van een algeheel base object. Dat hoeft dus totaal niet het geval te zijn. En daarom is er ook juist geen verschil tussen een primitive en een object in een taal als C++. Een primitive heeft ook een constructor en destructor, en je kunt ze ook als pointer/reference meegeven. En een object kan weer operator overloading toepassen zodat je er gewoon met operators mee kunt werken. Je kunt een primitive alleen niet subclassen, maar dat kun je bij een final class in java ook niet. Dus zowel in de taal als 'onder water' is er geen verschil

Als ik dan toch aan het ranten ben liefst zie ik dan de volgende overerving-tree:

code:

Object
+ Number (abstract: + - * / > < ==)
| + FloatingPointNumber (abstract: round floor ceil)
| | + Float
| | + Double
| | + bigfloat
| + IntegerNumber (abstract: % & | ^)
|   + int
|   + long
|   + bigint
+ Textual (abstract +)
| + char
| + String
+ bool (nee, een boolean is geen getal)

zie boven

[mbravenboer]

Ik zie dat er heel enthousiast wordt gedaan over toekomstige features van PHP. Ik kan dit goed begrijpen omdat PHP op dit moment een praktisch platform is en nu wellicht ook qua interne werking wat beter wordt.

Het blijft daarbij echter wel triest dat PHP ooit in de huidige vorm ontstaan is. Dit kan je van veel talen zeggen. Ik besef volledig dat dit erg flamering overkomt, maar ik wil dit toch even benadrukken met een reden...

De meeste features die nu binnenkort opgenomen worden in PHP zijn absoluut al zo'n 10 jaar niet controversieel meer. In het onderzoek naar programmeertalen worden er veel fraaie dingen bedacht (waarvan typering ongetwijfeld de grootste invloed heeft gehad). Deze zaken zijn dan een tijdje controversieel en worden gedurende een bepaalde periode bijgeschaafd totdat ze steeds algemener geaccepteerd zijn. Je ziet ze pas een flinke tijd daarna verschijnen in de programmeertalen die de massa programmeurs gebruikt: Java, C# en Python zijn hier denk ik goede voorbeelden van.

Het is wat mij betreft een doodzonde om zaken die al tijden algemeen geaccepteerd zijn als iets goeds niet op te nemen in een taal die pretendeert nuttig te zijn voor een programmeur. Als je zulke zaken niet opneemt in je taal ben je niet professioneel met je vak bezig en zou je geen talen moet maken die gebruikt moeten worden door de massa programmeurs. Gepruts op je eigen computer is prima, maar bevuil andere programmeurs niet met je eigen experimenten en leerproces. Het klinkt erg hard wellicht, maar ik hoop dat je me dat niet al te zeer kwalijk neemt . Misschien zegt het trouwens wel juist iets over de toestand van de informatica als dergelijke talen toch nog succesvol worden.

Ik kwam via Lambda the Ultimate een paar dagen geleden een zeer boeiende presentatie tegen van Robert Harper over programmeertalen. Deze man vatte het een en ander goed samen in een aantal uitspraken. De eerste ruim 10 slides zijn algemeen zeer nuttig, daarna wordt het een beetje onduidelijker voor de lezer. Hij bespreekt hier onder andere de problemen rond het doordringen van features tot de programmeertalen die 'in het veld' worden gebruikt.

Overigens moeten PHP aanhangers zich nu absoluut niet als enige beledigd voelen: er zijn veel talen die hetzelfde te verwijten valt, in het bijzonder ook Java en C#. Controversiele features opnemen in een veldtaal is absoluut onverstandig, maar belemmer de evolutie van programmeertalen niet. Geslachtsgemeenschap met succesvolle talen moet je dus niet vermijden.

Nog even over polymorphisme: het is vrij lastig om te praten over de ondersteuning van een de diverse features als er in de taal typen niet zichtbaar zijn. Veel van de verschijningsvormen van polymorphisme gaan eigenlijk uit van getypeerde variabelen: hoe kan je anders ooit een methode overloaden op basis van verschillende typen? En hoe kan je ooit met parametrisch polymorphisme gaan werken als er geen typen zijn? Zoals ACM heeft laten zien kent PHP echter absoluut wel vormen van polymorphisme.

[.oisyn]

mbravenboer schreef op 20 november 2002 @ 01:34:
Het is wat mij betreft een doodzonde om zaken die al tijden algemeen geaccepteerd zijn als iets goeds niet op te nemen in een taal die pretendeert nuttig te zijn voor een programmeur. Als je zulke zaken niet opneemt in je taal ben je niet professioneel met je vak bezig en zou je geen talen moet maken die gebruikt moeten worden door de massa programmeurs. Gepruts op je eigen computer is prima, maar bevuil andere programmeurs niet met je eigen experimenten en leerproces. Het klinkt erg hard wellicht, maar ik hoop dat je me dat niet al te zeer kwalijk neemt . Misschien zegt het trouwens wel juist iets over de toestand van de informatica als dergelijke talen toch nog succesvol worden.

maar dat is PHP ook, een taal voor hobbyisten, door hobbyisten. De interne werking van de Zend engine (zoals die geloof ik heet) is echt afschuwelijk, een zakje om braaksel in te deponeren is sterk aan te raden als je eens een kijkje gaat nemen in de achterliggende code

[mbravenboer]

.oisyn: maar dat is PHP ook, een taal voor hobbyisten, door hobbyisten.

Je kan je alleen afvragen hoeveel programmeurs er met PHP werken en toch tijdens hun PHP-werk buiten de doelgroep 'hobbyisten' vallen ... PHP pretendeert denk ik toch meer te zijn dan een hobby project en je kan je denk ik wel serieus afvragen hoeveel schade dat kan aanrichten.

Hum ik breng niet echt veel vrolijkheid in dit topic .

[.oisyn]

idd, het is in principe een uit de hand gelopen project wat nooit zover had mogen komen
En dan te bedenken dat het al 2 (!!) keer from scratch geschreven is na de eerste release (van versie 1 naar 2 en van 3 naar 4 geloof ik)

[whoami]

ACM schreef op 20 November 2002 @ 00:37:
[nohtml]
[...]
[/nohtml]
Wat gebeurd er bij:

PHP:

class super1
{
    function hello(){echo 'super1';}
}
class super 2
{
   function hello() {echo 'super2';}
}
class sub extends super1, super2
{
}

$sub = new sub();
$sub->hello();

En in dit simpele voorbeeld is het met overriding zo te voorkomen, maar als je wat grotere hierarchien hebt zie je het niet altijd aankomen. (je kan de compiler laten waarschuwen, maar is dat zo netjes?)

Ik snap niet wat je hier bedoelt met 'met overriding is dit te voorkomen'.
Is overriding hier van toepassing? super1 en super2 hebben alletwee een method met dezelfde naam, maar super1 en super2 hebben op dit niveau geen relatie met elkaar.
Het is pas in de class 'sub' dat er een probleem komt, en daar gaat de compiler een error gaan geven (wat idd zeer netjes is). sub weet namelijk niet of hij de method van super1 of van super2 moet gaan uitvoeren, dus dat moet je zelf gaan specifiëren.

[ACM]

.oisyn schreef op 20 November 2002 @ 00:43:
Om daarom maar gelijk een hele feature niet te ondersteunen, dus in het geval dat er weleens meerdere base classes met dezelfde members zouden kunnen zijn, vind ik een beetje onzin

Maar is de feature leuk of nuttig?
Imho leuk en zelden nuttig. Moet je die uitzonderings gevallen ondersteunen? Er lijkt me toch wel een reden dat een groot deel van de OO talen alleen maar single inheritance ondersteund.

ja, natuurlijk is dat netjes, er is namelijk ambiguiteit. Je zult de member expliciet op moeten geven. In C++ gaat dat zo:

C++:

Sub * sub = new Sub ();
sub->super1::hello ();
sub->super2::hello ();

Leuk... Maar wat als een conflict twintig niveau's diep zit?
Omdat je twee class-tree's samen trekt?

Vergeet even niet dat het om php gaat, een geinterpreteerde taal. Je wilt dus niet dat het compileren van je scriptje een halve minuut duurt (zoals bij C++ niet zo erg is), want dan komt niemand op je php-site (IE denkt na een halve minuut al dat er geen antwoord meer komt).

geen probleem waar je niet omheen komt dus

Waarom het jezelf moeilijk maken als het helemaal niet nodig is?
Hoevaak gebruik jij in C++ mulitple inheritance? En hoevaak had je het niet anders op kunnen lossen?

[ACM]

killercow schreef op 20 november 2002 @ 00:45:
jah das waar acm maar is het niet een beetje onlogisch? je wil toch een sub array aanspreken in een bepaalde opsitie in een array?

het is mischien wel logisch / makkenlijker om het met [1][2] te defineren en uit te lezen maar ik zou het eigenlijk zo willen hebben (logisch gezien dan) $array[1[2]] je wilt dus het object in hokje 2 van de array die in hokje 1 van $array zit hebben. ik weet niet, lijkt mij logischer.

Je moet het zo zien:
Zoek van de eerste dimensie element X op, beschouw dit element als een array en zoek daarin y op.
array[x][y] -> (array[x])[y] -> array_x[y]
Tenminste, dat is wat er bij c++ gebeurd/kan gebeuren (meen ik)

[drm]

Over de

code:

$string { 3 }

notatie, die is niet nieuw. Wordt in PHP4 al aangeraden om het met die notatie te doen, juist om te voorkomen dat men denkt dat een string in php een array is. Je kunt bijvoorbeeld niet zonder slag of stoot

code:

$str = "characters";
foreach ( $str as $ch ) { /* ... */ }

doen. Da's meer een symptoom dan een verklaring, maar kennelijk wil men in PHP niet de illusie wekken dat een string een array is, zoals dat in C het geval is. Kortom, het onderscheid tussen de 2 verschillende typen wordt benadrukt door een character in een string niet aan te roepen alsof de string een array is, maar door die gewoon een eigen syntax te geven. Ik vind dat zo gek nog niet.

[Verwijderd]

ACM schreef op 20 November 2002 @ 10:14:
Maar is de feature leuk of nuttig?
Imho leuk en zelden nuttig. Moet je die uitzonderings gevallen ondersteunen? Er lijkt me toch wel een reden dat een groot deel van de OO talen alleen maar single inheritance ondersteund.

Je hebt twee opties: of je ondersteunt single inheritance en interfaces, of je ondersteunt multiple inheritance. Zo gezien is multiple inheritance minstens zo nuttig als interfaces (minstens omdat je met multiple inheritance meer kunt dan met interfaces).

Leuk... Maar wat als een conflict twintig niveau's diep zit?
Omdat je twee class-tree's samen trekt?

Onmogelijk. Het conflict kan nooit dieper zitten dan één niveau, omdat de afgeleide classes de methodes van hun superclass erven.

Waarom het jezelf moeilijk maken als het helemaal niet nodig is?
Hoevaak gebruik jij in C++ mulitple inheritance? En hoevaak had je het niet anders op kunnen lossen?

Even vaak als een java-programmeur interfaces gebruikt. En ja, dat kun je anders oplossen, maar dat is niet zo netjes of inefficient.

[ACM]

Verwijderd schreef op 20 november 2002 @ 13:09:
Onmogelijk. Het conflict kan nooit dieper zitten dan één niveau, omdat de afgeleide classes de methodes van hun superclass erven.

Ik bedoel het anders
Stel je voegt de boel samen (door twee ervingen) in class X. En in parent X-20 in boom A en parent X-10 in boom B zitten methoden die dezelfde aanroep hebben.

Het conflict treed op in de class X, dat begrijp ik ook wel. Maar de oorzaak van het conflict zit ergens in class X-10 vs X-20.
En als je daar als programmeur rekening mee moet houden kon het wel eens lastig worden.

Of mis ik iets?

[whoami]

Verwijderd schreef op 20 november 2002 @ 13:09:
[...]

Je hebt twee opties: of je ondersteunt single inheritance en interfaces, of je ondersteunt multiple inheritance. Zo gezien is multiple inheritance minstens zo nuttig als interfaces (minstens omdat je met multiple inheritance meer kunt dan met interfaces).


Even vaak als een java-programmeur interfaces gebruikt. En ja, dat kun je anders oplossen, maar dat is niet zo netjes of inefficient.

[/quote]

Inheriten van classes (implementation inheritance) en inheriten van interfaces (interface inheritance) zijn toch 2 verschillende dingen.
Bij implementation inheritance kan je functionaliteit inheriten terwijl bij interface inheritance je gaat gaan specifieren van : deze class moet deze functionaliteit kunnen bieden.

[.oisyn]

ACM schreef op 20 November 2002 @ 10:14:
Maar is de feature leuk of nuttig?

zowel leuk als nuttig

Imho leuk en zelden nuttig. Moet je die uitzonderings gevallen ondersteunen? Er lijkt me toch wel een reden dat een groot deel van de OO talen alleen maar single inheritance ondersteund.

zoals ik al zei, omdat het best tricky kan zijn om het te implementeren, zoals cyclische child-parent relaties (maar dat valt ook wel weer mee als je je er even in verdiept). Maar goed, nu ik erover nadenk is dat idd te hoog gegrepen voor die php devvers, daar ik niet zo'n hoge pet van hun op heb

Leuk... Maar wat als een conflict twintig niveau's diep zit?
Omdat je twee class-tree's samen trekt?

zoals mietje zei kan dat dus niet. Je hebt altijd maar een bepaalde methode die conflict met diezelfde methode als de andere classtree waarvan je van overerft. Dat is precies hetzelfde probleem als daarnet, en dus gewoon op te lossen

Vergeet even niet dat het om php gaat, een geinterpreteerde taal. Je wilt dus niet dat het compileren van je scriptje een halve minuut duurt (zoals bij C++ niet zo erg is), want dan komt niemand op je php-site (IE denkt na een halve minuut al dat er geen antwoord meer komt).

bullshit, compileertijd heeft daar zo goed als niets mee te maken. Dat het bij C++ over het algemeen er zo lang over doet om te compileren is omdat er veel diskaccess plaats vind door de enorme hoeveelheid aan header files die geinclude worden. Het idee van de traditionele scanners en parsers is dat de scan en parsetijden in constante tijd een bepaalde lengte aan code doorlopen, het aantal ondersteundefeatures heeft daar weinig mee te maken

Waarom het jezelf moeilijk maken als het helemaal niet nodig is?
Hoevaak gebruik jij in C++ mulitple inheritance? En hoevaak had je het niet anders op kunnen lossen?

In C++ ben je verplicht multiple inheritance te gebruiken als je gebruik wilt maken van interfaces, dus dat is sowieso niet anders op te lossen, maar implementation inheritance gebruik ik ook regelmatig. Dat ik het ook anders op had kunnen lossen is echt een non-argument, je kunt ook OO coden in een niet OO taal, maar of dat nou zo verstandig is...

[ACM]

.oisyn schreef op 20 november 2002 @ 13:50:
bullshit, compileertijd heeft daar zo goed als niets mee te maken. Dat het bij C++ over het algemeen er zo lang over doet om te compileren is omdat er veel diskaccess plaats vind door de enorme hoeveelheid aan header files die geinclude worden. Het idee van de traditionele scanners en parsers is dat de scan en parsetijden in constante tijd een bepaalde lengte aan code doorlopen, het aantal ondersteundefeatures heeft daar weinig mee te maken

Het programmeren in php gaat naar per class een file, niks mis mee. Maar bij goed OO stop je ook niet te veel functionaliteit in 1 class (althans, dat lijkt me zo ), kortom veel functionaliteit -> veel classes -> veel files...


PHP kent een constructie waarbij het belangrijk is dat de functionaliteit snel beschikbaar is op het moment dat er een request komt, ondanks dat alles nog geparsed en gecompileerd moet worden. Elke extra check (zeker complexe checks) verslomen dat alleen maar. Dat het bij c++ een halve seconde langer duurt boeit niet, zo vaak compileer je het niet. Bij php maakt dat wel uit. (gebruikers verwachten dat het er 'on click' is)

[.oisyn]

Ten eerste is die check er alleen maar als er multiple inheritance is, en ten tweede is die check er sowieso al omdat er gekeken moet worden welke methoden geoverload moeten worden (inclusion overloading) voor de vtable. Dat zo'n check een halve seconde gaat duren is echt onzin, zo'n check is slechts enkele cpu instructies, laten we zeggen hoogstens 1000 clockcycles (en dat zijn er nog veel, inclusief memory reads), en als we uitgaan van een 1 GHz processor duurt dat dus slechts 1 microseconde per class. Dat ga jij echt niet merken hoor