[php5] Eindelijk 'echte' OOP?

Pagina: 1
Acties:
  • 113 views sinds 30-01-2008
  • Reageer

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
In dit document wordt uitgelegd wat php5 / zend engine 2.0 (hoogstwaarschijnlijk) zal gaan ondersteunen.

Daarmee mag php zich, volgens mij, toch wel een object georienteerde taal gaan noemen (in die zin: je *mag* er OO in programmeren).

Zijn jullie het met de stelling eens (en waarom wel/niet)?

Acties:
  • 0 Henk 'm!

Verwijderd

Nee, een engine met workarounds kan ik niet echt OO noemen (valt dus niet te moddelleren). en dan refereer ik aan de "__construct" functie

Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

C++ is ook niet echt OO, toch kan je er OO in werken ...
Het is zelfs discutabel of Java wel echt OO is ;) (paradigma alles is een Object en elk Object is een instantie van een Klasse gaat niet overal op, vooral bij de metaclasses en de simpele typen gaat dat mis)

Maar met deze wijzigingen zou je wel echt OO moeten kunnen werken in PHP.

[ Voor 13% gewijzigd door ACM op 14-04-2003 11:40 ]


Acties:
  • 0 Henk 'm!

  • drm
  • Registratie: Februari 2001
  • Laatst online: 09-06 13:31

drm

f0pc0dert

markvleth:
Nee, een engine met workarounds kan ik niet echt OO noemen
De taal moet OO zijn. Heeft imo helemaal niets met de engine te maken. Als de taaldefinitie een prima OO structuur beschrijft, dan kan de engine nog zo brak zijn, maar is de taal gewoon OO.
(valt dus niet te moddelleren). en dan refereer ik aan de "__construct" functie
En wat is er dan mis met een __construct ? Of je de constructor nou de naam van de class geeft of de naam __construct, wat heeft dat te maken met modelleren :?



Overigens is hier een complete beschrijving van de zend 2.0 engine te vinden. Ook kun je een leuke discussie nalezen op javahova.net, ook over de zend 2.0 engine.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz


Acties:
  • 0 Henk 'm!

  • nhimf
  • Registratie: September 2000
  • Laatst online: 03-09 09:46

nhimf

Lekker belangrijk allemaal

Ik zou het OO noemen zodra ik er minimaal private/protected/public members in een class kan stoppen en dat ik kan overerven.
Graag zou ik ook zien dat je overloading kan doen en overriding.
Dan noem ik het OO. (ookal is het dan nog geen OO, want je mist oa abstractie)

edit:

ik heb even snel door die documentjes gekeken en het ziet er naar uit dat het duidelijk _wel_ OO is. Ik zie abstractie, overerving, private/protected members.
Overriding lijkt mij ook dat het erinzit, anders heb je wat problemen met abstracte members ;). Overloading kon ik zo niet vinden.
Het is iig zeer interresant dezze vernieuwingen.

[ Voor 41% gewijzigd door nhimf op 14-04-2003 12:02 ]

Ik stink niet, ik ruik gewoon anders


Acties:
  • 0 Henk 'm!

Verwijderd

Ach ik ben zo en zo tegen php, ik heb er een afkeer tegen vanwege het feit dat het veel te veel te veel uitnodigd om smerige code op te leveren. Dus een echt objectieve mening zul je uit mij niet kunnen trekken, blijf dat php een underdog vinden...

Alleen ik vraag me wel af hoe je de contrustor nu vastlegt in een UML diagram? Als een functie? dat zou bagger zijn...

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:21
Iets is pas OO als je:
- data hiding kunt doen (private/protected modifiiers)
- kunt overerven
- polymorfisme hebt.

Pas als je die 3 dingen hebt, kan je zeggen dat een taal OO is imho.

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

whoami schreef op 14 april 2003 @ 12:01:
Iets is pas OO als je:
- data hiding kunt doen (private/protected modifiiers)
- kunt overerven
- polymorfisme hebt.

Pas als je die 3 dingen hebt, kan je zeggen dat een taal OO is imho.
Smalltalk is OO, toch? :)
Maar Smalltalk kent, bij mijn weten, geen data hiding...

Imho is er niet echt een harde definitie te stellen, OO is nogal abstract. Maar als de primaire werking van een taal met objecten is, zou je kunnen zeggen dat het OO is.

Java, Smalltalk, Python, Javascript (!), e.v.a.
't Is dan maar de vraag of het een 'object based' (zoals C++ en imho php dan ook) of 'object oriented' (smalltalk, python (?), java) taal is trouwens

[ Voor 34% gewijzigd door ACM op 14-04-2003 12:07 ]


Acties:
  • 0 Henk 'm!

  • nhimf
  • Registratie: September 2000
  • Laatst online: 03-09 09:46

nhimf

Lekker belangrijk allemaal

Verwijderd schreef op 14 April 2003 @ 12:00:
Ach ik ben zo en zo tegen php, ik heb er een afkeer tegen vanwege het feit dat het veel te veel te veel uitnodigd om smerige code op te leveren. Dus een echt objectieve mening zul je uit mij niet kunnen trekken, blijf dat php een underdog vinden...

Alleen ik vraag me wel af hoe je de contrustor nu vastlegt in een UML diagram? Als een functie? dat zou bagger zijn...
Een constructor is toch een functie? Alleen roep je deze met het aanmaken van het object aan.
En dat je smerige code kan schrijven... ASP kan het net zo goed.
C++ wel eens gezien, kan je heel smerig mee coden.
Je kan met alle talen smerig coden, alleen bij sommige wordt je wat meer gedwongen om mooi te coden (bijv C#, java).
Maar dat een taal "slecht" is vanwege het feit dat je smerig kan coden zegt imho meer iets over de programmeur dan de taal.

Ik stink niet, ik ruik gewoon anders


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op 14 April 2003 @ 12:00:
Ach ik ben zo en zo tegen php, ik heb er een afkeer tegen vanwege het feit dat het veel te veel te veel uitnodigd om smerige code op te leveren. Dus een echt objectieve mening zul je uit mij niet kunnen trekken, blijf dat php een underdog
check Orbb eens (zie sig) :P

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • nhimf
  • Registratie: September 2000
  • Laatst online: 03-09 09:46

nhimf

Lekker belangrijk allemaal

ACM schreef op 14 April 2003 @ 12:04:
[...]

Smalltalk is OO, toch? :)
Maar Smalltalk kent, bij mijn weten, geen data hiding...
Het is dan iig geen pure OO taal, maar die zijn er bij mijn weten niet in overvloed.
Meeste OO talen zijn niet echt 100% OO.
Data hiding is een eis voor een pure OO taal.

Ik stink niet, ik ruik gewoon anders


Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

nhimf schreef op 14 april 2003 @ 12:05:
Een constructor is toch een functie? Alleen roep je deze met het aanmaken van het object aan.
Owja, constructors... Das ook zoiets waarom Java geen OO is :+

Elke methode moet een methode op een Object zijn... Een constructor is dat niet in java...
nhimf schreef op 14 april 2003 @ 12:07:
Het is dan iig geen pure OO taal, maar die zijn er bij mijn weten niet in overvloed.
Meeste OO talen zijn niet echt 100% OO.
Data hiding is een eis voor een pure OO taal.
Onzin, Smalltalk is, bij mijn weten, meer OO dan Java...

Ik denk dat dit wel een aardige uitleg is:
Uit de OOFaq :)

[ Voor 32% gewijzigd door ACM op 14-04-2003 12:16 ]


Acties:
  • 0 Henk 'm!

  • nhimf
  • Registratie: September 2000
  • Laatst online: 03-09 09:46

nhimf

Lekker belangrijk allemaal

ACM schreef op 14 April 2003 @ 12:09:
[...]

Owja, constructors... Das ook zoiets waarom Java geen OO is :+

Elke methode moet een methode op een Object zijn... Een constructor is dat niet in java...

[...]

Onzin, Smalltalk is, bij mijn weten, meer OO dan Java...
Ik zeg ook niet dat Java meer OO is dan Smalltalk, daar ken ik smalltalk te weinig voor. Ik zeg alleen dat smalltalk geen puur OO is (en java ook niet ;) )

edit:

eigenlijk ken ik Smalltalk alleen van naam, op school wel eens iets over gehad, maar nooit gebruikt.

[ Voor 12% gewijzigd door nhimf op 14-04-2003 12:13 ]

Ik stink niet, ik ruik gewoon anders


Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

nhimf schreef op 14 April 2003 @ 12:12:
Ik zeg ook niet dat Java meer OO is dan Smalltalk, daar ken ik smalltalk te weinig voor. Ik zeg alleen dat smalltalk geen puur OO is (en java ook niet ;) )

edit:

eigenlijk ken ik Smalltalk alleen van naam, op school wel eens iets over gehad, maar nooit gebruikt.
Toevallig laatst college over gehad hier ;)

Anyway, ik zie in die link van mij hierboven drie definities voor OO:
1. object-oriented = data abstractions + object types + type inheritance
2. Object-Oriented = Classes and Objects + Inheritance + Communication with messages
3. 7 "Elements of the Object Model"; 4 major and 3 minor:
code:
1
2
3
4
5
6
7
8
9
  Major:
    Abstraction
    Encapsulation
    Modularity
    Hierarchy  (Inheritance)
  Minor:
    Typing
    Concurrency
    Persistence

Die laatste is wel erg uitgebreid ;)

Of dit lijstje:
  • 1 Level System
    All objects can be viewed as classes and all classes can be viewed as objects (as in Self). There is no need for Meta-Classes because objects describe themselves. Also called "single-hierarchy" systems. There is only 1 kind of object.
  • 2 Level System (C++)
    All Objects are instances of a Class but Classes are not accessible to programs (no Meta-Class except for in the compiler and perhaps for type-safe linkage, as in C++). There are 2 kinds of distinct objects: objects and classes.
  • 3 Level System (Java)
    All objects are instances of a class and all classes are instances of Meta-Class. The Meta-Class is a class and is therefore an instance of itself (really making this a 3 1/2 Level System). This allows classes to be first class objects and therefore classes are available to programs. There are 2 kinds of distinct objects (objects and classes), with a distinguished class, the metaclass.
  • 5 Level System (Smalltalk)
    Like a 3 Level System, but there is an extra level of specialized Meta-Classes for classes. There is still a Meta-Class as in a 3 Level System, but as a class it also has a specialized Meta-Class, the "Meta-Class class" and this results in a 5 Level System:
    • object
    • class
    • class class (Smalltalk's Meta-Classes)
    • Meta-Class
    • Meta-Class class

[ Voor 45% gewijzigd door ACM op 14-04-2003 12:21 ]


Acties:
  • 0 Henk 'm!

  • drm
  • Registratie: Februari 2001
  • Laatst online: 09-06 13:31

drm

f0pc0dert

whoami
Iets is pas OO als je:
- data hiding kunt doen (private/protected modifiiers)
Dat wordt lastig. Zoals je in dat draadje op javahova kunt lezen, heb je de modifiers wel, maar wordt er geen foutmelding gegeven als je een private member probeert te benaderen, "om performance redenen" 7(8)7
Ik weet overigens niet of ze daar sinds de alpha release nog op teruggekomen zijn
- kunt overerven
Dat kon al ;)
- polymorfisme hebt.
Polymorfisme is wel een leuke trouwens. Je kunt dat in PHP op 2 manieren benaderen:
  • Polymorfisme is iets wat per definitie ondersteund wordt, omdat het een weaktyped taal is
  • Polymorfisme wordt niet ondersteund, omdat polymorfisme bestaat bij de gratie van typechecking
;)

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz


Acties:
  • 0 Henk 'm!

Verwijderd

.oisyn schreef op 14 april 2003 @ 12:06:
[...]


check Orbb eens (zie sig) :P
Ik had er al naar gekeken, ik ben benieuwd. Dat het beter wordt als php lijkt me logisch.


En Nhimf:
Php is op zo'n manier toegankelijk (weak-typed en aantal argumenten in functie hoeven niet overeen tekomen ) dat het niet aanmoedigd om beter te proggen, dus het is een taal die aanmoedigd om slecht te proggen. (maar genoeg offtopic, want het gaat erom of het OO is of niet, en het lijkt me dus duidelijk: niet)

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:21
drm schreef op 14 April 2003 @ 12:45:
[...]
Dat wordt lastig. Zoals je in dat draadje op javahova kunt lezen, heb je de modifiers wel, maar wordt er geen foutmelding gegeven als je een private member probeert te benaderen, "om performance redenen" 7(8)7
Ik weet overigens niet of ze daar sinds de alpha release nog op teruggekomen zijn
Lol. 8)7 Het nut van dat keyword ontgaat me dan toch echt wel hoor. :+
Polymorfisme is wel een leuke trouwens. Je kunt dat in PHP op 2 manieren benaderen:
  • Polymorfisme is iets wat per definitie ondersteund wordt, omdat het een weaktyped taal is
  • Polymorfisme wordt niet ondersteund, omdat polymorfisme bestaat bij de gratie van typechecking
;)
Hmmm.... Niet ondersteund dus. :)

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • drm
  • Registratie: Februari 2001
  • Laatst online: 09-06 13:31

drm

f0pc0dert

[b]markvleth[/]:
Php is op zo'n manier toegankelijk (weak-typed en aantal argumenten in functie hoeven niet overeen tekomen ) dat het niet aanmoedigd om beter te proggen, dus het is een taal die aanmoedigd om slecht te proggen.
Ik vind dat je een behoorlijk aparte manier van redeneren hebt. Als je in een bepaalde taal programmeert, is het de taaldefinitie die bepaalt of jij goed programmeert of slecht programmeert. Namelijk: als jij slecht programmeert krijg je een foutmelding c.q. waarschuwing c.q. notice (vergeet E_ALL niet), en anders werkt 't zoals je verwacht, namelijk volgens de taaldefinitie.

Dat er vervolgens programmeurs zijn die brakke constructies gaan gebruiken en/of verzinnen is geen voorwaarde voor een slechte taal. Ik kan in Java ongetwijfeld ook allerlei zieke constructies bedenken. Maakt dat Java een slechte/lelijke programmeertaal? Nee, dat maakt mij een prutser.

Overigens krijg je bij geen geldig aantal argumenten keurig een foutmelding in PHP.
(maar genoeg offtopic, want het gaat erom of het OO is of niet, en het lijkt me dus duidelijk: niet)
Heb je dat PDF'je wel gelezen?

whoami:
Lol. 8)7 Het nut van dat keyword ontgaat me dan toch echt wel hoor. :+
Ik lees dat ze daar op teruggekomen zijn. Je krijgt nu wel een Fatal error.
Da's trouwens ook niet goed voor de performance, zo'n fatal error :+
Hmmm.... Niet ondersteund dus. :)
Of wel. Het ligt er maar aan hoe je het bekijkt, imo :)

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

whoami schreef op 14 April 2003 @ 13:09:
Hmmm.... Niet ondersteund dus. :)
Niet mee eens, polymorphisme hoeft niet per se op basis van type. In C++ is er bijvoorbeeld een vorm van (compile-time) polymorphisme dmv templates. De STL Iterators zijn daar een goed voorbeeld van.

Een basic iterator heeft een increment-operatie (operator ++), iets om de iterator te dereferencen, dus om de huidige waarde uit te lezen (operator *), en om ze te vergelijken met andere iteratoren (operator == en !=).
De functies die deze iterators accepteren zijn allemaal templated functies, waar je in principe elk soort object aan kan geven, zolang de ++, *, == en != maar gedefinieerd is voor dat type. Dit kunnen simpele objecten zijn als gewone pointers naar objecten, maar ook hele ingewikkelde objecten zoals map::iterator, die door een hele boom-structuur itereert.

Of je dat nou doet dmv virtual functions, dus waarbij at runtime wordt bepaald wat er moet worden aangeroepen, of gewoon templates, waarbij at compiletime de functie kan worden bepaald, doet er weinig toe. Het blijft polymorphisme.

In diezelfde redenatie is er ook polymorphisme in PHP en Orbb. Een object hoeft niet per se te voldoen aan een bepaald type. Als je een functie aanroept wordt at runtime de functie bij de naam gezocht, aan de hand van het type van het object. Welk type dat is doet er niet toe, als die functie (of variabele natuurlijk) maar bestaat.
In Orbb kun je dit overigens zelf ook controleren met de instanceof operator vergelijkbaar met java. Als een object niet aan een bepaald type voldoet kun je een error geven. Maar wat is het nut daarvan? Als dat object nou gewoon alle functies die je wilt gebruiken bevat, waarom moet ie dan ook per se van een bepaald type zijn?

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:21
.oisyn schreef op 14 april 2003 @ 13:26:
[...]


Niet mee eens, polymorphisme hoeft niet per se op basis van type. In C++ is er bijvoorbeeld een vorm van (compile-time) polymorphisme dmv templates. De STL Iterators zijn daar een goed voorbeeld van.
Idd, templates zijn ook een vorm van polymorphisme.
Een basic iterator heeft een increment-operatie (operator ++), iets om de iterator te dereferencen, dus om de huidige waarde uit te lezen (operator *), en om ze te vergelijken met andere iteratoren (operator == en !=).
De functies die deze iterators accepteren zijn allemaal templated functies, waar je in principe elk soort object aan kan geven, zolang de ++, *, == en != maar gedefinieerd is voor dat type. Dit kunnen simpele objecten zijn als gewone pointers naar objecten, maar ook hele ingewikkelde objecten zoals map::iterator, die door een hele boom-structuur itereert.
Dit klinkt als een interface.
Als een class een bepaalde interface implementeert dan kan je toch op min of meer zeggen dat die class van het 'type' v/d interface is?
In diezelfde redenatie is er ook polymorphisme in PHP en Orbb. Een object hoeft niet per se te voldoen aan een bepaald type. Als je een functie aanroept wordt at runtime de functie bij de naam gezocht, aan de hand van het type van het object. Welk type dat is doet er niet toe, als die functie (of variabele natuurlijk) maar bestaat.
Hmmm.... Stel, je hebt volgende constructie:
code:
1
2
3
4
5
6
7
Persoon* arrPers[2];

arrPers[0] = new Arbeider();
arrPers[1] = new Bediende();

arrPers[0]->BerekenLoon();
arrPers[1]->BerekenLoon();


Stel daarbij dat de classes Arbeider en Bediende afgeleid zijn van de class Persoon, en dat BerekenLoon in Persoon een virtuele functie is en in de classes Arbeider en Bediende ge-overrided is.
In C++ zal hier at runtime de juiste BerekenLoon method uitgevoerd worden. Dus niet de BerekenLoon functie van Persoon , maar de berekenLoon functie van (in het eerste geval) Arbeider, en in het tweede geval van Bediende.
Als ik jouw uitleg lees, dan zou in PHP (of in Orbb) wel de BerekenLoon functie van Persoon uitgevoerd worden, en niet die van arbeider of Bediende?

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • drm
  • Registratie: Februari 2001
  • Laatst online: 09-06 13:31

drm

f0pc0dert

In C++ zal hier at runtime de juiste BerekenLoon method uitgevoerd worden. Dus niet de BerekenLoon functie van Persoon , maar de berekenLoon functie van (in het eerste geval) Arbeider, en in het tweede geval van Bediende.
Als ik jouw uitleg lees, dan zou in PHP (of in Orbb) wel de BerekenLoon functie van Persoon uitgevoerd worden, en niet die van arbeider of Bediende?
Nee. In PHP wordt keurig de BerekenLoon van resp. Arbeider en Bediende aangeroepen. Dat is zelfs in de huidige engine al zo. Daar hoef je dus niet over te discussieren :P

Overigens heb je in PHP ook een soort 'instanceof', nl. is_a ()

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

whoami schreef op 14 April 2003 @ 13:41:
Dit klinkt als een interface.
Als een class een bepaalde interface implementeert dan kan je toch op min of meer zeggen dat die class van het 'type' v/d interface is?
Het is ook een interface waaraan ze moeten voldoen, maar dat wordt dus niet geforceerd door ze een bepaalde interface te laten implementeren, en die objecten dus ook van dat type worden. Je kunt in C++ die iterators niet casten naar een iterator interface oid, noch is er een mogelijkheid om op te leggen dat de template parameters aan die interface moet voldoen (je krijgt compile-errors als dat niet zo is simpelweg omdat de compiler bijvoorbeeld de ++ operator niet kan vinden bij dat type, maar dat is dus een error achteraf)
Als ik jouw uitleg lees, dan zou in PHP (of in Orbb) wel de BerekenLoon functie van Persoon uitgevoerd worden, en niet die van arbeider of Bediende?
Nee, in Orbb wordt dat dit:

code:
1
2
3
4
var arrPers = [new Arbeider (), new Bediende ()];

arrPers[0]->BerekenLoon();
arrPers[1]->BerekenLoon();


arrPers[0] is van het type Arbeider, en arrPers[1] is van het type Bediende. Bij het opzoeken van de methode wordt dus ook bij resp. Arbeider en Bediende gezocht, en niet bij persoon. Tenzij ze overerven van Persoon, en de methode BerekenLoon () niet gedefinieerd is in Arbeider en Bediende, in welk geval bij de superklasse (Persoon dus) wordt gezocht naar die methode

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

whoami schreef op 14 April 2003 @ 12:01:
Iets is pas OO als je:
- data hiding kunt doen (private/protected modifiiers)
Hier nog even over.
Ik denk dat je die eis beter kan vervangen door encapsulation. Het hebben van variabelen/data in een object dus, ipv specifieke eisen te stellen aan de toegang tot die data :)

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:21
ACM schreef op 14 April 2003 @ 15:37:
[...]

Hier nog even over.
Ik denk dat je die eis beter kan vervangen door encapsulation. Het hebben van variabelen/data in een object dus, ipv specifieke eisen te stellen aan de toegang tot die data :)
Ik zou het niet vervangen maar er wel bijvoegen. :)
data encapsulation en data hiding dan. :)

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

Ik vind het 'hiden' van data dmv private/protected members niet echt bepaald een eis van OO, meer een methode om het voor de gebruiker 'netter' te maken. Of alle members nou public zijn of niet, het blijft object georienteerd als je met objecten werkt die hun eigen verantwoordelijkheden hebben en eigenschappen kennen.

Ik vind dit lijstje van ACM dan ook het beste:
code:
1
2
3
4
5
6
7
8
9
  Major:
    Abstraction
    Encapsulation
    Modularity
    Hierarchy  (Inheritance)
  Minor:
    Typing
    Concurrency
    Persistence

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • Glimi
  • Registratie: Augustus 2000
  • Niet online

Glimi

Designer Drugs

(overleden)
whoami schreef op 14 April 2003 @ 13:41:
Idd, templates zijn ook een vorm van polymorphisme.
Err... niet specefiek genoeg.

Parametric polymorphism en Inclusion polymorphism ( degene die je bedoeld ) zijn beide een vorm van Universal polymorphism. Dat is polymorfisme welke op een oneindig aantal types werkt, welke iets gemeen met elkaar hebben. Het gedrag is wel gelijk.

Je hebt echter ook Ad-hoc polymorphisme, welke op n types werkt, waarbij n gelimiteerd is. Denk hierbij aan Coercion (conversie van types) en Overloading.
Deze methodes hebben vaak totaal verschillend gedrag en de types hebben geen relatie met elkaar.

Inclusion polymorphisme is de polymorphisme eis voor OO. Voor de duidelijkheid: Java ondersteund (1.4) MINDER polymorphisme als C++
Tot zover de types polymorphism gespecialiseerd door Cardelli en Wegner (85).

Er is echter nog veel meer flexibel te maken aan een class. Als je @ runtime methodes kunt gaan opzoeken, waarom dat niet members? Of base classes?

Het volgende komt uit Chen, Sun en Tang en heb ik pas gebruikt in een presentatie:

Java:
1
2
3
4
5
6
7
8
interface Window { ... }
class SunWindow implements Window{ ... }
class MacWindow implements Window{ ... }
class WinWindow implements Window{ ... }

interface EditorWindow extends Window { ... }
class SunEditWindow implements EditorWindow{ ... }
//enz

Nogal rottig om die implementatie 2x te gaan doen, plus dat het nu geen SunWindow meer is
Dat is te vervangen door
Java:
1
class SunEditWindow extends SunWindow implements EditorWindow

Wat ik nou niet echt heerlijk vind. Je hebt nu twee keer vastgelegd dat het een Window is, wat nou ook niet echt nodig is.
Waarom dat niet vervangen met een nieuw type polymorfisme:
Java:
1
2
3
4
5
6
7
8
interface Window { ... }
class SunWindow implements Window{ ... }
class MacWindow implements Window{ ... }
class WinWindow implements Window{ ... }

interface EditorWindow virtual extends Window { ... }
class SunEditWindow implements EditorWindow<Window is SunWindow>{ ... }
//enz

Dan zou SunEditWindow direct erven van Sunwindow.

Verder is ook nog polymorphisme mogelijk op members:
Java:
1
2
3
4
5
6
7
8
9
10
11
12
class Motor{ ... }
class TurboMotor extends Motor{ ... }
class SuperMotor extends Motor{ ... }

class Auto {
   protected Motor _m;
}
class TurboAuto extends Auto {

  // _m is niet van type te veranderen.
  // dus we moeten constant casten
}

Zou het niet mooier zo kunnen:
Java:
1
2
3
4
5
6
7
8
9
10
11
12
class Motor{ ... }
class TurboMotor extends Motor{ ... }
class SuperMotor extends Motor{ ... }

class Auto {
   virtual protected Motor _m;
}
class TurboAuto extends Auto : Motor is TurboMotor{

  // _m is van type te TurboMotor.
  // dus we moeten niet casten
}


Dit is allemaal te bereiken met simpele templates die kunnen werken met constraints. Leuke daarvan is dat Java dus deze vorm van polymorphisme wel ondersteund vanaf 1.5 :)

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

C++ kent dat allang, en het is in principe gewoon te bereiken door multiple inheritance en virtual base classes

C++:
1
2
3
4
5
class Window { /* ... */ };
class SunWindow : public virtual Window { /* ... */ };

class EditorWindow : public virtual Window { /* ... */ };
class SunEditWindow : public SunWindow, public EditorWindow { /* ... */ };


Die imho brakke java oplossing is puur omdat java geen volledige multiple inheritance ondersteund. Als ze dat nou eens gingen toevoegen, samen met virtual base classes, dan ben je van het hele gezeur af :)


.edit: goed, dit vereist natuurlijk dat je base classes op hun beurt weer een virtual base class hebben, wat lang niet altijd het geval is (en source-code aanpassen is natuurlijk geen optie). Gelukkig hebben we templates:

C++:
1
2
3
4
5
6
7
8
9
10
11
12
class Window { }; // een abstracte class
class EditWindow { }; // ook een abstracte class

template <class WIN>
class EditWinImpl : public EditWindow, public WIN { };


    // implementatie van een Window :
class MSWindow : public Window { };

    // implementatie van een EditWindow, gebaseerd op MSWindow
class MSEditWindow : public EditWinImpl<MSWindow> { };



En tot slot, jawel, de virtual members:

C++:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
template <class T, class AS>
struct AutoCaster
{
    T *& t;

    AutoCaster (T *& pT) : t (pT) { }

    operator AS * ()
    {
        return static_cast<AS *> (t);
    }

    operator const AS * () const
    {
        return static_cast<const AS *> (t);
    }

    AS * operator -> ()
    {
        return static_cast<AS *> (t);
    }
    
    const AS * operator -> () const
    {
        return static_cast<const AS *> (t);
    }

    AutoCaster & operator = (AS * as)
    {
        t = as;
        return *this;
    }

    /*
    TODO: operator & () implementeren, die een object
    teruggeeft wat zich voordoet als een T**
    */
};


struct Motor
{
    virtual void engage () = 0;
};

struct GasMotor : public Motor
{
    void engage ();
    void gasSpecificFunction ();
}

struct DieselMotor : public Motor
{
    void enage ();
    void dieselSpecificFunction ();
};


struct Car
{
    Motor * motor;
};

template <class MOTOR> class CarImpl
{
    AutoCaster<Motor, MOTOR> sMotor;
    CarImpl () : sMotor (motor) { }
};

struct GasCar : public Car<GasMotor>
{
    GasCar ()
    {
        motor = new GasMotor ();
    }
};

struct DieselCar : public Car<DieselMotor>
{
    DieselCar ()
    {
        motor = new DieselMotor ();
    }
};

void test ()
{
    GasCar g;
    Car & c = g;

    // all following function calls work on same object
    g.motor->engage ();
    g.gasMotor->gasSpecificFunction ();

    c.motor->engage ();
}


I O+ C++

Hoewel je er natuurlijk beter voor kunt kiezen om de hele AutoCaster constructie achterwege te laten, en gewoon GasMotor en DieselMotor een member laten zijn van resp. GasCar en DieselCar, en dan de Motor * naar die member laten wijzen

[ Voor 68% gewijzigd door .oisyn op 14-04-2003 17:56 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:21
offtopic:

in C# zal dat ook mogelijk zijn. :)
In C#, we can supply an optional list of constraints for each type parameter declared in our generic class. A constraint indicates a requirement that a type must fulfill in order to construct a generic type. Constraints are declared using the where keyword, followed by a &#8220;parameter-requirement&#8221; pair where the &#8220;parameter&#8221; must be one of those defined in the generic type, and the &#8220;requirement&#8221; must be a class or interface.

In order to satisfy our need to use the CompareTo method in the Dictionary class, we can impose a constraint on the KeyType type parameter, requiring any type passed to the first parameter of the Dictionary class to implement the IComparable interface, like so:
code:
1
2
3
4
5
6
7
8
9
10
11
public class Dictionary<KeyType, ValType> where KeyType : IComparable
{
    public void Add(KeyType key, ValType val)
    {
        ...
        switch(key.CompareTo(x))
        {
        }
        ...
    }
}

Now, when compiled, our code will be checked to ensure that each time we use the Dictionary class, we are passing as a first parameter a type that implements the IComparable interface. Further, we no longer have to explicitly cast our variable to an IComparable interface before calling the CompareTo method.


edit:
damn, door het weglaten van die nohtml tag was m'n code niet zoals ze moest zijn

[ Voor 5% gewijzigd door whoami op 14-04-2003 18:18 ]

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:21
Misschien wat miereneuken oisyn, maar waarom kies je ervoor om Motor, DieselMoter, etc als een struct te implementeren en niet als een class?

Ik weet wel dat een struct ook member functions kan bevatten, maar de ongeschreven regel is toch: als iets member functions heeft, maak er dan een class van.

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

Dat scheelt me weer een public: tikken :P
Ik gebruik in test-opstellingen altijd structs, omdat ik me dan niet bezig hoef te houden met access modifiers... die zijn standaard dan namelijk public :)

Als ik ze in een serieus project zou verwerken zou ik er idd classes voor maken. Volgens mij maakt het niet eens zoveel uit, en is het gewoon een kwestie van voorkeur

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Na een rondje langs wat OO talen gedaan te hebben:
Verwijderd schreef op 14 april 2003 @ 10:03:
Daarmee mag php zich, volgens mij, toch wel een object georienteerde taal gaan noemen (in die zin: je *mag* er OO in programmeren).
Conclusie: ja, vanaf php5 ondersteunt php object orientatie!!

Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Het is dus geen object georienteerde taal ;)
Tenzij vanaf dan ineens alles een object is, elk object een instantie van een klasse is en methoden op objecten werken.

Je kan er wel OO in programmeren, maar met wat moeite kan je ook wel OO programmeren in C... (iig iets dat er veel op lijkt :P )
Maar dat zegt nog niet dat je er dus niet gewoon vrij goed in OO kan P, het biedt er zat functionaliteit voor, hoewel dat met php5 dus hopelijk beter wordt :) En ja, in andere talen is het soms nog beter geregeld.

Maarreuh, php4 is net zo goed al geschikt voor OOP hoor, zie dit forum als bewijs daarvoor :)

[ Voor 9% gewijzigd door ACM op 14-04-2003 22:44 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
ACM schreef op 14 april 2003 @ 22:43:
Maarreuh, php4 is net zo goed al geschikt voor OOP hoor,
Daar kan ik het toch niet helemaal mee eens zijn.
PHP4 ondersteunt wel wat dingetjes, maar essentiele dingen als data-hiding ontbreken toch echt!
zie dit forum als bewijs daarvoor :)
Maar daar heb ik de source nog nooit van gezien :p.

Acties:
  • 0 Henk 'm!

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Verwijderd schreef op 15 April 2003 @ 11:55:
Daar kan ik het toch niet helemaal mee eens zijn.
PHP4 ondersteunt wel wat dingetjes, maar essentiele dingen als data-hiding ontbreken toch echt!
Datahiding is helemaal niet essentieel...
.oisyn schreef op 14 April 2003 @ 16:06:
Ik vind het 'hiden' van data dmv private/protected members niet echt bepaald een eis van OO, meer een methode om het voor de gebruiker 'netter' te maken. Of alle members nou public zijn of niet, het blijft object georienteerd als je met objecten werkt die hun eigen verantwoordelijkheden hebben en eigenschappen kennen.
Ik ben het daarin iig volledig eens met .oisyn :)

Sterker nog, in het lijstje dat .oisyn daar quote:

code:
1
2
3
4
5
6
7
8
9
  Major:
    Abstraction
    Encapsulation
    Modularity
    Hierarchy  (Inheritance)
  Minor:
    Typing
    Concurrency
    Persistence

Voldoet php aan vrij veel :)
Abstraction -> als dat het interfaces/abstract classes verhaal is van Java, dan voldoet het daar niet echt aan nee.
Encapsulation -> voldoet het aan (maar dan zonder datahiding)
Modularity -> dat ook (tenminste, ik neem aan dat dat het hele principe van objecten is ;) )
Hierarchy -> zelfs dat
Typing -> jaja, zelfs dat (tot op zekere hoogte dan) ;)
Concurrency -> als ze daarmee threading bedoelen, dan niet :)
Persistence -> Euh... Dat objecten static members kunnen hebben? Dat kent php ook niet echt, tenzij je global vars gaat meenemen en/of de static vars in een functie :)

Acties:
  • 0 Henk 'm!

Verwijderd

ACM schreef op 15 April 2003 @ 12:37:
Datahiding is helemaal niet essentieel...
Misschien niet door een of andere defenitie. But like we care, het moet er wat mij betreft wel in zitten(en nee ik ga daar niet over...) wil het OO genoemd worden, al dan niet serieus genomen worden...

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

ACM:

Concurrency lijkt me geen threading iets, maar meer iets als dat je meerdere systemen naast elkaar kan draaien. Ik denk dat ze ermee bedoelen dat je meerdere instanties van een bepaalde klasse naast elkaar kunt gebruiken, in tegenstelling tot procedureel programmeren, waar je een setje functies maakt die op 1 ding werken. Mijn uitleg is vast heel onduidelijk, vandaar een voorbeeld: stel je hebt een aantal grafische functies om op het scherm te maken. Als je dat naar OO zou vertalen dan maak je een Display klasse. Concurrency is dan dat je meerdere instanties van een Display klasse kunt hebben, die ieder hun eigen state bijhouden.

En met persistence wordt bedoeld de mogelijkheid om objecten op te slaan op een medium, zodat je ze tijdens een andere 'sessie' weer uit kunt laden. Dus meer de mogelijkheid om objecten om te zetten naar een datastroom en een datastroom weer om te zetten naar objecten. PHP heeft hier ook features voor voor zover ik weet (serialization)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

Verwijderd

php5 kent geen nameless objecten. Dat is ook een groot nadeel.

In java kan je zeggen object.getSubObject().executeMethod();

in php5 kan je niet zeggen:
$object->getSubObject()->executeMethod();

maar moet je
$tmpObject = $object->getSubObject();
$tmpObject->executeMethod();

Dat vind ik persoonlijk nog een grote misser in php

Acties:
  • 0 Henk 'm!

  • chem
  • Registratie: Oktober 2000
  • Laatst online: 11-09 11:19

chem

Reist de wereld rond

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<?
class a
{
    var $b;
    function a()
    {
        $this->b = new b();
    }
    function b()
    {
        return $this->b;
    }
}
class b
{
    function a()
    {
        return 'waa?';
    }
}

$b = new a();
echo $b->b()->a();
?>

werkt toch echt hoor.

Klaar voor een nieuwe uitdaging.


Acties:
  • 0 Henk 'm!

Verwijderd

Owh, dat wist ik niet! Waarschijnlijk heb ik dat ooit alleen bij een heeele oude php-installatie geprobeerd.

Ik vind wel cool dat ze het weak-type principe wat verzwakt hebben, doordat je kan afdwingen dat een parameter van een bepaald type moet zijn, bijvoorbeeld:

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<?php
interface Foo {
    function a(Foo $foo);
}

interface Bar {
    function b(Bar $bar);
}

class FooBar implements Foo, Bar {
    function a(Foo $foo) {
        // ...
    }

    function b(Bar $bar) {
        // ...
    }
}

$a = new FooBar;
$b = new FooBar;

$a->a($b);
$a->b($b);
?> 

[ Voor 3% gewijzigd door Verwijderd op 08-07-2003 13:18 ]


Acties:
  • 0 Henk 'm!

Verwijderd

In reactie op Keessie131 -> Komt er ook de mogelijkheid tot overloading? Voorbeeld:
PHP:
1
2
3
4
5
6
7
8
9
10
11
<?
class Foo {
  function bar() {
    echo "test!";
  }
 
  function bar(int i, Foo o) {
    echo "test2!";
  }
}
?>

[ Voor 9% gewijzigd door Verwijderd op 08-07-2003 13:49 ]


Acties:
  • 0 Henk 'm!

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 07-10-2022
sKiLL4: Komt er ook de mogelijkheid tot overloading? Voorbeeld:
PHP:
1
2
3
4
5
6
7
8
9
10
11
<?
class Foo {
  function bar() {
    echo "test!";
  }
 
  function bar(int i, Foo o) {
    echo "test2!";
  }
}
?>
Hierbij kan de aan te roepen procedure nog bepaald worden op basis van het aantal argumenten. Dit lijkt mij een wat interessanter voorbeeld:
PHP:
1
2
3
4
5
6
7
8
9
10
11
<?
class Foo {
  function bar(int i) {
    echo "test!";
  }
 
  function bar(Foo o) {
    echo "test2!";
  }
}
?>

[ Voor 8% gewijzigd door mbravenboer op 08-07-2003 13:52 ]

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Acties:
  • 0 Henk 'm!

  • chem
  • Registratie: Oktober 2000
  • Laatst online: 11-09 11:19

chem

Reist de wereld rond

Verwijderd schreef op 08 juli 2003 @ 13:49:
In reactie op Keessie131 -> Komt er ook de mogelijkheid tot overloading? Voorbeeld:
PHP:
1
2
3
4
5
6
7
8
9
10
11
<?
class Foo {
  function bar() {
    echo "test!";
  }
 
  function bar(int i, Foo o) {
    echo "test2!";
  }
}
?>
Neem ff de moeite om op php.net te kijken dan.

Klaar voor een nieuwe uitdaging.


Acties:
  • 0 Henk 'm!

  • Kaastosti
  • Registratie: Juni 2000
  • Laatst online: 20:49

Kaastosti

Vrolijkheid alom!

Naar mijn idee is OO alleen maar een _manier_ van programmeren. Je kunt met C++ en java net zo goed sequentieel gaan 'programmeren' door alles bijv. in main() te zetten. Niet dat het prettig werkt, maar toch.

Net zo goed als dat je in PHP met klassen en objecten kan werken en zo je code OO maakt. PHP is wat dat betreft wel lastiger om _goed_ te doen, aangezien code al vrij snel werkt. Dat komt door nonchalante wijze waarom PHP met z'n variabelen (en bijv. typecasting) omgaat. Als je je dat maar realiseert en echt wat moois neer wil zetten, kun je ook met PHP best goede OO code schrijven.

Bij C++ en java wordt je er min of meer tot verplicht, aangezien programma's al snel onoverzichtelijk worden en niet meer willen werken als je het niet OO opzet. Ja, het kan uiteraard wel, maar werkt simpelweg niet prettig.

Een vergissing is menselijk, maar om er echt een puinhoop van te maken heb je een computer nodig.


Acties:
  • 0 Henk 'm!

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 07-10-2022
Kaastosti: Dat komt door nonchalante wijze waarom PHP met z'n variabelen (en bijv. typecasting) omgaat.
Dat is niet nonchalant of slordig: dat is een fundamenteel ander type systeem. Het gaat wat ver om dat direct nonchalant te noemen. Java is statisch getypeerd: at compile time moet het type van elke expressie bekend zijn. In PHP (en vele andere talen) is dit niet zo: ze hebben een dynamisch type systeem.

Dit heeft echter niets met OO te maken. Veel talen die mensen als 'echte OO' talen zien zijn statisch getypeerd, maar dat betekent niet dat OO iets met statische typering te maken heeft. Sterker nog: Smalltalk is bijvoorbeeld dynamisch getypeerd en wordt vaak genoemd in het rijtje van talen waarmee OO begonnen is.

Zie ook:
http://www.wikipedia.org/wiki/Object-oriented_programming

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Acties:
  • 0 Henk 'm!

  • Kaastosti
  • Registratie: Juni 2000
  • Laatst online: 20:49

Kaastosti

Vrolijkheid alom!

Mjah nonchalant was ook niet precies het woord wat ik zocht. In ieder geval wordt er een stuk makkelijker mee om gegaan dan in bijvoorbeeld C++ of Java, waar je expliciet typecasting uit moet voeren.

Maar in weze ben je het dus wel met mij (en anderen hier) eens dat OO niets te maken heeft met de taal zelf, maar met de manier waarop er in geprogrammerd wordt.

Een vergissing is menselijk, maar om er echt een puinhoop van te maken heb je een computer nodig.


Acties:
  • 0 Henk 'm!

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 07-10-2022
Kaastosti: Maar in weze ben je het dus wel met mij (en anderen hier) eens dat OO niets te maken heeft met de taal zelf, maar met de manier waarop er in geprogrammerd wordt.
Zeker, met dat neemt niet weg dat ik het op andere punten niet met je eens was ;) .

Maar Idd dus: Een taal is niet OO, een taal biedt OO faciliteiten. Je kan prima op een object georienteerde wijze programmeren in een taal die geen OO faciliteiten aanbiedt. Het hele punt is dan echter dat het een stuk lastiger te realiseren is, waardoor OO achtig programmeren voor minder ervaren programmeurs eerder een nadeel dan een voordeel wordt. Typerend voorbeeld hiervan is dat sommige boeken over (functionele) talen een OO achtige wijze van programmeren vaak in een van de laatste hoofstukken introduceren.

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

Kaastosti schreef op 08 July 2003 @ 14:30:
Mjah nonchalant was ook niet precies het woord wat ik zocht. In ieder geval wordt er een stuk makkelijker mee om gegaan dan in bijvoorbeeld C++ of Java, waar je expliciet typecasting uit moet voeren.
waarbij in C++ het weer mogelijk is door oa operator overloading een dynamisch type te maken ;)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • Kaastosti
  • Registratie: Juni 2000
  • Laatst online: 20:49

Kaastosti

Vrolijkheid alom!

Tuurlijk is dat mogelijk... je _kunt_ natuurlijk alles mogelijk maken ;)

Een vergissing is menselijk, maar om er echt een puinhoop van te maken heb je een computer nodig.


Acties:
  • 0 Henk 'm!

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 07-10-2022
Kaastosti: je _kunt_ natuurlijk alles mogelijk maken ;)
http://www.wikipedia.org/wiki/Computability_theory

(jaja, erg flauw)

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment

Pagina: 1