[PHP] procedureel versus OO

[Genoil]

Ik ga binnenkort een revisie schrijven van een CMS-achtig systeem in PHP. De oude was zgn. 'procedureel' opgezet, zeg maar "C-style" functies, netjes gegroepeerd in files-to-be-included (ook qua naamgeving erg 'clean').

Nu overweeg ik voor de nieuwe versie over te stappen naar OO, zeg maar "C++/Java style". Dat ken ik van m'n ervaring met C++ en Java en het is natuurlijk prachtig, maar ik ben nou niet bepaald kapot van de OO implementatie in PHP4. Dit vanwege <vul hier alles in wat PHP5-OO wel heeft>.

Daarnaast heb ik m'n vraagtekens bij PHP-OO en de "stateless-heid" van HTTP. Waar ik OO met name toegepast heb in client applicaties als games en editors in C++, Java en Lingo en dus mooie "persistent" object-structuren had, zie ik er het nut niet helemaal van in om na elke GET/POST request weer een hele zooi classes te moeten instantieren op basis van wat sessie-muk (of erger nog, in sessies geserializde objecten weer moet deserializen). Dit wat betreft de globale applicatie-structuur.

Voor tijdelijke gegevensopslag tijdens de afhandeling van een request gebruik ik in PHP altijd associatieve arrays. Ik heb ook wel es met objecten geprobeerd, maar het feit dat een object verkregen uit een "mysql_fetch_object" niet eens gecast kan worden naar een custom-made class zodat ik er direct methods van kan aanroepen vinnik toch wel tamelijk brak. Nee, eerst middels een truucje het enkelvoudige constructor-probleem omzeilen en omkitten naar je eigen object...
Dan fiets ik liever een associatieve resultset rechtstreeks door een kale functie, toch, of mis ik iets?

Een ander punt dat ik m'n uiteindelijke beslissing mee moet nemen, is dat "klant" bij de presentatie van ons aanvankelijke plan weinig interesse toonde in hippe zaken als XML en XSLT. Hij gaat liever voor "lean and mean", "rough en ready" PHP+MySQL = HTML. Bij nader inzien wel cool eigenlijk (fuk XML ). Wat heeft dit met PHP-OO te maken? s n e l h e i d ! Ik moet toegeven het nog nooit getest te hebben maar volgens mij is PHP-OO veel trager dan de procedurele aanpak. Is dit eigenlijk echt zo?

Onder jullie zijn er vast genoeg die voor dezelfde keuze hebben gestaan en er uiteindelijk 1 gemaakt hebben, ben benieuwd wat en waarom, en wat je op basis van je ervaringen mij aanraadt. Nee mijn lichte voorkeur voor de procedurele aanpak schuif ik niet onder stoelen of banken . Maar mischien zijn er ook mensen die beide handig combineren?

[whoami]

Waarom denk je dat OO trager is dan procedureel in executie-tijd? Ik heb zelf geen ervaring met PHP, maar als er al een verschil is, zal dat toch wel miniem zijn.

Ik weet ook niet in welke mate PHP OO is, maar OO ontwerpen en coderen heeft toch een aantal voordelen, zoals code-hergebruik, data-encapsulatie, abstractie, ....

[Nielsz]

OO heeft in beginsel weinig te maken met caching n.a.v. sessies of iets dergelijks. Het is de hele opzet van de software.

code:

$item = new item();
$item->doiets();
$item->save();

Dit is imo 'iets' mooier dan een insert enzo...
En OO is misschien iets trager, maar dat ligt dan vooral aan jezelf

[Alarmnummer]

whoami schreef op 17 oktober 2002 @ 16:26:
Waarom denk je dat OO trager is dan procedureel in executie-tijd? Ik heb zelf geen ervaring met PHP, maar als er al een verschil is, zal dat toch wel miniem zijn.

Ik weet ook niet in welke mate PHP OO is, maar OO ontwerpen en coderen heeft toch een aantal voordelen, zoals code-hergebruik, data-encapsulatie, abstractie, ....

Heeft php intussen al goed werkende access modifiers? Er staat mij bij dat er oa geen foutmeldingen werden opgeworpen als je een access violation had.

En bezit php intussen ook polymorphisme? En trouwens zonder multiple inheritance (eventueel dmv interfaces) kan je trouwens niet veel leuke oo sofwtare schrijven. Heeft php dit wel?

Ik heb een beetje de indruk gekregen dat er wat oo achtige features zijn toegevoegd, maar je het niet kan zien als een volwaardige oo taal. Misschien dat iemand mij kan verlichten

[raptorix]

MMM, snelheid is nauwelijks belangrijk, als je al in problemen komt met snelheid komt dat meestal door andere zaken, zoals een te trage database, een te lichte webserver of mega brak programmeer werk.

Daarnaast ben ik van mening dat als snelheid echt een probleem wordt op je website dat je gewoon moet gaan cachen.

Hoewel dat natuurlijk niet wil zeggen dat er maar op een luie manier geprogt moet worden.

[drm]

zie ook Voordeel van classes?

[whoami]

Alarmnummer schreef op 17 oktober 2002 @ 16:33:
[...]

Heeft php intussen al goed werkende access modifiers? Er staat mij bij dat er oa geen foutmeldingen werden opgeworpen als je een access violation had.

En bezit php intussen ook polymorphisme? En trouwens zonder multiple inheritance (eventueel dmv interfaces) kan je trouwens niet veel leuke oo sofwtare schrijven. Heeft php dit wel?

Ik heb een beetje de indruk gekregen dat er wat oo achtige features zijn toegevoegd, maar je het niet kan zien als een volwaardige oo taal. Misschien dat iemand mij kan verlichten

Nou, dat vroeg ik me ook af. Ik weet niet hoever PHP daarmee staat, maar als die dingen er idd nog niet inzitten, dan kun je PHP -net als VB6- niet als een OO Language beschouwen.

[whoami]

Als je voor een OO opzet gaat, dan zal je hoogstwaarschijnlijk langer bezig zijn met de design-fase als je het goed wilt aanpakken, maar daar pluk je later wel de vruchten van als je dingen gaat moeten aanpassen.

[Nielsz]

Alarmnummer schreef op 17 oktober 2002 @ 16:33:
[...]

Heeft php intussen al goed werkende access modifiers? Er staat mij bij dat er oa geen foutmeldingen werden opgeworpen als je een access violation had.

En bezit php intussen ook polymorphisme? En trouwens zonder multiple inheritance (eventueel dmv interfaces) kan je trouwens niet veel leuke oo sofwtare schrijven. Heeft php dit wel?

Ik heb een beetje de indruk gekregen dat er wat oo achtige features zijn toegevoegd, maar je het niet kan zien als een volwaardige oo taal. Misschien dat iemand mij kan verlichten

* pakt bouwlamp *
Vanaf versie 4.3.0 (is nu een 'prerelease' van uit) is het OO. Nu is het nog prutsOO. Multiple inheritance is mogelijk via een omweg.

[drm]

Nielsz:
Multiple inheritance is mogelijk via een omweg.

* drm vindt dat echt dikke onzin.
Dan maar geen multiple inheritance.

[Genoil]

tsja ik moet eerlijk bekennen dat dit topic idd wel een beetje een ouwe koe is, maar ivm de komende PHP5 zal de discussie straks ook wel weer overnieuw gevoerd worden.

Wat ik in veel topics hierover aangedragen zie worden, is de betere overzichtelijkheid van OOP tov PP (procedural programming). Ik zie echter m'n include files als een soort objecten, waarbij ik elke functie gewoon nette namen geef, 2 of 3 letters voor de modulenaam, dan de 'classnaam' en dan de functienaam. Membervariabelen maak ik gewoon globals van die beginnen met "m_" (daar heb ik er meestal geen van, zoveel heb je er immers imho niet aan in een stateless omgeving). En omdat PHP4-OOP toch geen private members heeft, zijn die globals niet veel "vuiler" dan class member vars. Krijg je bijvoorbeeld:

PHP:

function KN2_FORM_SplitObjects($aFormData, $aRules);
function KN2_FORM_CheckObject($aObject, $aRules);   
function KN2_FORM_CheckAttribute($className, $name, $value, $aRule);
function KN2_FORM_CreateError($name, $description, $error); 
function KN2_FORM_Check($aFormData, $aRules);

design hiervan nog verre van echt af btw

Dus als ik een formcheck wil wil doen, doe ik gewoon:

PHP:

include("lib/kn2_form.php");
include("myspecificrulesforthisform.php");
$result = KN2_FORM_Check($_POST);

een OOP versie zou zoiets zijn:

PHP:

include("classes/kn2_form.php");
include("myspecificrulesforthisform.php");
$KN2_FORM = new KN2_FORM($aRules);
$result = $KN2_FORM->Check($_POST, $aRules);

wat is hier nou overzichtelijker aan? Als er nou meerdere form-posts tegelijk afgehandeld moesten worden, tsja, maar zo zit HTTP niet in elkaar

Overigens is het wel grappig om te zien dat veel PHP-OOPers trots hun (bijvoorbeeld) MySQL (wrapper-)classes laten zien, terwijl zo een class in de meeste gevallen typisch 'static' zou moeten zijn, hetgeen PHP dan weer niet heeft.
In die gevallen, zoals m'n form checker, maakt het dus echt geen moer uit, en vast inderdaad ook niet qua snelheid.

Waar het (ik heb zitten spitten in OOP topics) werkelijk om draait, is het gemak en de snelheid van het gebruik van objecten als container van dynamische variabelen.
En dat gaat uiteindelijk in PHP nergens over. Het feit dat je in Java private member variabelen van binnenuit de class gewoon bij de naam kan noemen terwijl hij toch voor buitenaf dicht blijft is prachtig, in PHP kost het je toch elke keer weer een reference wanneer je met $this->var bij je member wilt komen terwijl het kreng ook nog steeds via $instancename->var te bereiken is.

En dan wil ik ook nog eens de conversieslag onderstrepen die je meestal moet doen vanuit bijvoorbeeld een SQL resultset naar je tijdelijke object-stcuctuur. Overigens zijn die associatieve arrays van php nog eens veel handiger omdat de keys daarvan veel lekkerder zijn te manipuleren dan object members.

Ook is ergens in een topic voor mij het voordeel "inheritance" als sneeuw voor de zon verdwenen, vanwege de weak-typing van PHP...

Ja i've made up my mind... alweer...ik zag namelijk tijdens het zoeken nog een post van mezelf van 1,5 jaar terug waar ik hetzelfde in wat minder woorden zei...maarja toen was ik nog een PHP-newbie uit OOP-world

[LuCarD]

Nielsz schreef op 17 oktober 2002 @ 16:44:
[...]

* pakt bouwlamp *
Vanaf versie 4.3.0 (is nu een 'prerelease' van uit) is het OO. Nu is het nog prutsOO. Multiple inheritance is mogelijk via een omweg.

Doe het lampje weer uit....

Versie 4.3.0 is nog steeds Zend Engine V1.2

PHP 5 wordt pas echt OO interresant, dan kunnen mensen zoals Alarmnummer ook hun ei kwijt.

Q2 of Q3 2003.

Je kan al wel een redelijk stabiele versie downloaden. Maar het is dan wel PHP4.2.3 met ZE2

[Nielsz]

LuCarD schreef op 17 oktober 2002 @ 17:35:
[...]


Doe het lampje weer uit....

Versie 4.3.0 is nog steeds Zend Engine V1.2

PHP 5 wordt pas echt OO interresant, dan kunnen mensen zoals Alarmnummer ook hun ei kwijt.

Q2 of Q3 2003.

Je kan al wel een redelijk stabiele versie downloaden. Maar het is dan wel PHP4.2.3 met ZE2

Hoe weet je dat? Ik ga er al maanden vanuit dat 4.3 ZE2 is
Linkje?

[LuCarD]

http://groups.google.com/...9605.mail.yahoo.com#link1

Helaas nog niet....

Ik wacht ook ZE2, hier word gezegd dat hij "early 2003" uit komt (dat is Q1), maar meestal loopt het wel uit. En het was een optimistische schatting.... Helaas...

Dus Q2 of Q3 is realistischer....

[Zoijar]

Alarmnummer schreef op 17 oktober 2002 @ 16:33:

En bezit php intussen ook polymorphisme? En trouwens zonder multiple inheritance (eventueel dmv interfaces) kan je trouwens niet veel leuke oo sofwtare schrijven. Heeft php dit wel?

Ik heb een beetje de indruk gekregen dat er wat oo achtige features zijn toegevoegd, maar je het niet kan zien als een volwaardige oo taal. Misschien dat iemand mij kan verlichten

PHP heeft naar mijn weten altijd al polymorphisme ondersteund. Wat veel mensen vergeten is dat PHP geen strongly typed taal is. Hierdoor zijn heel veel dingen al impliciet mogelijk.

Zie bv deze code:

PHP:

<?php 

class A {
    function A () {
        print('A constructed<BR>');
    }

    function foo() {
        print('A::foo()<BR>');
    }

    function ola() {
        print('A::ola()<BR>');
    }
}

class B extends A {
    function B() {
        A::A();
        print('B constructed<BR>');
    }

    function foo() {
        print('B::foo()<BR>');
    }
}

// Here we do something on an A object
function blah(&$classA) {
    $classA->foo();
    $classA->ola();
}

$b = new B();
blah($b);

?>

En hoeveel moeite moet je in C++ wel niet doen om een equivalent van dit te krijgen:

PHP:

    function &factory($classname) {
        $classpath = 'class/'.$classname.'.class.php';

        if (file_exists($classpath)) {
            require_once($classpath);
            $obj = &new $classname();
            return $obj;
        } else return false;
    }

Ik zeg niet dat PHP een goeie OO taal is hoor, in de verste verte niet. Maar met wat truckjes kan je er heel redelijk OO in proggen zoals bovenstaande code fragmentjes laten zien.
Ik heb op mn werk in ieder geval een heel OO framework gebouwd, om alles vanaf index.php te laten gebeuren, en dan op basis van getvars en XML config files alles dispatched. Werkt erg lekker, gebruik een afgeleide class van een standaard view, overload wat dingetjes daar en ik heb automatisch een nieuwe pagina.

[-RenE-]

Om even op je vraag terug te komen: Er wordt je gevraag een revisie van een bestaand, netjes geprogrammeerd, CMS te maken.

Waarom ga je dan aan OO denken, waarbij het complete design van de applicatie over gedaan kan worden. Hebben jullie geld en tijd teveel ofzo?

[Nielsz]

LuCarD schreef op 17 oktober 2002 @ 20:49:
http://groups.google.com/...9605.mail.yahoo.com#link1

Helaas nog niet....

Ik wacht ook ZE2, hier word gezegd dat hij "early 2003" uit komt (dat is Q1), maar meestal loopt het wel uit. En het was een optimistische schatting.... Helaas...

Dus Q2 of Q3 is realistischer....

It already is - go to www.php.net, and search for
'alpha'.
http://www.php.net/do_dow...0-dev-zend2-alpha2.tar.gz

En hier draait dus wel een 4.3 met Zend2

[curry684]

Alarmnummer schreef op 17 oktober 2002 @ 16:33:
En bezit php intussen ook polymorphisme? En trouwens zonder multiple inheritance (eventueel dmv interfaces) kan je trouwens niet veel leuke oo sofwtare schrijven. Heeft php dit wel?

C++ is de enige algemeen bekende taal die true multiple inheritance ondersteunt, dus dat is niet echt een leidraad... Java en C# werken beide op single inheritance met interface implements support.

Daarnaast heb ik m'n vraagtekens bij PHP-OO en de "stateless-heid" van HTTP. Waar ik OO met name toegepast heb in client applicaties als games en editors in C++, Java en Lingo en dus mooie "persistent" object-structuren had, zie ik er het nut niet helemaal van in om na elke GET/POST request weer een hele zooi classes te moeten instantieren op basis van wat sessie-muk (of erger nog, in sessies geserializde objecten weer moet deserializen). Dit wat betreft de globale applicatie-structuur.

En exact wie houdt je tegen om een stay-alive op die persistent structuren te parkeren van 15 minuten zodat je custom garbage collector ze pas wegkiepert als de sessie een kwartier niet gebruikt is? Mocht iemand pas na 20 minuten responderen kun je ze alsnog unstreamen.

(zo werken ISAPI's iig bij mij)

[whoami]

[nohtml]

curry684 schreef op 18 oktober 2002 @ 10:14:
[...]

C++ is de enige algemeen bekende taal die true multiple inheritance ondersteunt, dus dat is niet echt een leidraad... Java en C# werken beide op single inheritance met interface implements support.

Idd.
Ik zie multiple inheritance dan ook niet als een essentieel OO feature. Daarom is het imho ook uit talen als Java en C# weggelaten.
Single inheritance is wel essentieel, maar ik snap niet waarom jij -als Javahova- vind dat multiple inheritance een must is?

[Genoil]

-RenE- schreef op 17 oktober 2002 @ 22:09:
Om even op je vraag terug te komen: Er wordt je gevraag een revisie van een bestaand, netjes geprogrammeerd, CMS te maken.

Waarom ga je dan aan OO denken, waarbij het complete design van de applicatie over gedaan kan worden. Hebben jullie geld en tijd teveel ofzo?

Nee zo zit het niet helemaal in elkaar. Laat ik zeggen dat het bestaande ding prima werkt, dus logisch en functioneel best aardig in elkaar zit, maar qua programmeerwerk niet geschikt is voor de gang van v1.0 naar v2.0. Of de term revisie dan op z'n plaats is, geen idee, ik ben 'slechts' een interaction designer die best aardig kan coden, nooit 1 fatsoenlijk boek over software design uitgelezen , laat staan er les in gehad. Misschien is 'rewrite' beter op z'n plaats.

Tijd en geld natuurlijk hebben we natuurlijk niet in deze barre tijden... Enthousiasme, fascinatie voor het werk en wilskracht helpen je er wat dat beteft stukken beter door

curry684 schreef op 18 oktober 2002 @ 10:14:

En exact wie houdt je tegen om een stay-alive op die persistent structuren te parkeren van 15 minuten zodat je custom garbage collector ze pas wegkiepert als de sessie een kwartier niet gebruikt is? Mocht iemand pas na 20 minuten responderen kun je ze alsnog unstreamen.

(zo werken ISAPI's iig bij mij)

Euhm...say whaaat?!? Wie houdt mij tegen:
1. ikzelf? dit is toch wel een kilometer boven mijn pet
2. de klant? hij heeft al een 'heavyweight' CMS monster in J2EE door een andere partij laten ontwikkelen en waardeert ons juist om de eenvoud van onze ontwerpen.
3. PHP(-CGI) op klant z'n SGI servert? Leg me anders eens uit hoe je bovenstaande met PHP ISAPI doet? Klinkt wel doop

[LuCarD]

Nielsz schreef op 18 oktober 2002 @ 10:11:
[...]


[...]

En hier draait dus wel een 4.3 met Zend2

Hmmm... Jij wilt dus een PreRelease PHP draaien met een alpha engine

Ik wens je veel plezier...

Ow... hij draait wel oke... Maar of je binnenkort jouw code in live situatie kan gebruiken betwijfel ik...

Helemaal omdat PHP zelf ondertussen ook nog verandert.

[Nielsz]

LuCarD schreef op 18 oktober 2002 @ 10:39:
[...]


Hmmm... Jij wilt dus een PreRelease PHP draaien met een alpha engine

Ik wens je veel plezier...

Ow... hij draait wel oke... Maar of je binnenkort jouw code in live situatie kan gebruiken betwijfel ik...

Helemaal omdat PHP zelf ondertussen ook nog verandert.

Ik draai 'm zelf niet hoor
Maar maak mij maar eens wijs dat een Prerelease van 4.3 die met ZE2 alpha werkt strax in de release weer teruggaat naar ZE1

[LuCarD]

Nielsz schreef op 18 oktober 2002 @ 10:47:
[...]


Ik draai 'm zelf niet hoor
Maar maak mij maar eens wijs dat een Prerelease van 4.3 die met ZE2 alpha werkt strax in de release weer teruggaat naar ZE1

Die link is alleen voor mensen die ZE2 willen testen deze heeft niks met de huidige versie te maken...

Sorry...

[Glimi]

Ontopic: Glimi in "Voordeel van classes?"

Dat is de enige reden dat ik voor OO zou kiezen in PHP ipv PP

[Alarmnummer]

whoami schreef op 18 oktober 2002 @ 10:22:
[nohtml]
[...]

Idd.
Ik zie multiple inheritance dan ook niet als een essentieel OO feature. Daarom is het imho ook uit talen als Java en C# weggelaten.
Single inheritance is wel essentieel, maar ik snap niet waarom jij -als Javahova- vind dat multiple inheritance een must is?

Het is ook zeker niet een verplichte oo feature, maar het wordt een stuk lastiger als je het niet kan gebruiken En verder beschouwen jullie multiple inheritance als iets dat moet gebeuren van een class, en dat hoeft zeker niet. Classes en Interfaces zijn allemaal types en je kan dus een nieuw type maken op basis van meerdere types, en is Java in mijn ogen ook een multiple inheritance taal *weet dat het wel vrij ongebruikelijk is om er zo over te praten in de oo wereld dus ik begrijp ook zeker wat jullie bedoelen*

[whoami]

Alarmnummer schreef op 18 oktober 2002 @ 11:09:
[...]

Het is ook zeker niet een verplichte oo feature, maar het wordt een stuk lastiger als je het niet kan gebruiken En verder beschouwen jullie multiple inheritance als iets dat moet gebeuren van een class, en dat hoeft zeker niet. Classes en Interfaces zijn allemaal types en je kan dus een nieuw type maken op basis van meerdere types, en is Java in mijn ogen ook een multiple inheritance taal *weet dat het wel vrij ongebruikelijk is om er zo over te praten in de oo wereld dus ik begrijp ook zeker wat jullie bedoelen*

Ja, multiple inheritance op interface niveau kan perfect in Java en C#, maar imho kan je pas van multiple inheritance spreken als je dat ook kan op implementatie-niveau, en dat kan niet in Java en C#.
Bij interface inheritance geef je enkel aan welke interface een class moet aanbieden, en dan vind ik het woordje inheritance eigenlijk misleidend. Ik kan met de beste wil van de wereld niet begrijpen wat je dan uiteindelijk overerft. Niets toch? Je zegt gewoon dat de class de gedefinieerde functies in de interface implementeert.

Maar goed, dat is mijn mening.

[Zoijar]

offtopic:
multiple inheritance is vooral nodig voor traits en policy classes. C++ ontwerp hangt tegenwoordig erg op die twee concepten.

[Genoil]

offtopic:
zou het komen dat de forumpolitie denkt dat het niveau in /14 daalt vanweg het feit dat hoogdravende discussies over multiple inherintance terecht komen in [PHP] topics ?

[vinnux]

Alarmnummer schreef op 17 oktober 2002 @ 16:33:
[...]
En trouwens zonder multiple inheritance (eventueel dmv interfaces) kan je trouwens niet veel leuke oo sofwtare schrijven.

Waarom zou je zonder multiple inheritence geen leuke dingen kunnen maken. Java heeft dit ook niet, vanwege al die nadelen die het met zich mee brengt. En met java kun je verdomt leuke dingen doen. Kwestie van goed ontwerpen.
Multiple inheritence === BAH

[Zoijar]

Wat voor nadelen dan? Het is een extra feature, er kunnen dus alleen maar voordelen zijn; want als je het gewoon niet gebruikt is het precies hetzelfde als een taal zonder deze feature :-)
Buiten de logische verklaring, de nadelen vallen behoorlijk mee. Je moet alleen er voor zorgen dat je geen diamand vormen etc maakt. Maar zelfs dan heb je in C++ dus nog virtual multiple inheritance. En voor ambiguiteit heb je de scope resolution operator.

[Alarmnummer]

opm naar vgouw:
Je moet mijn stukje nog even beter doorlezen

Als ik eerlijk ben weet ik niet zo goed wat ik nog moet denken van java. Ik erger me oa groen en geel aan het feit dat je geen operator overloading hebt. En verder vind ik dat je er maar vanuit moet gaan, dat de programmeur goed genoeg met leuke/ingewikkelde features kan omgaan. Dus wie weet is multi inheritance inclusief implementatie zo slecht nog niet eens.

[whoami]

Alarmnummer schreef op 18 oktober 2002 @ 11:51:
Als ik eerlijk ben weet ik niet zo goed wat ik nog moet denken van java. Ik erger me oa groen en geel aan het feit dat je geen operator overloading hebt. En verder vind ik dat je er maar vanuit moet gaan, dat de programmeur goed genoeg met leuke/ingewikkelde features kan omgaan. Dus wie weet is multi inheritance inclusief implementatie zo slecht nog niet eens.

/offtopic:
straks gaat hij nog naar .NET overstappen, als ik zo al jouw bemerkingen die over Java hebt de laatste tijd lees....

[Alarmnummer]

Een taal is een vervoersmiddel en niet een doel, als zich iets beters voordoet dan stap ik met veel plezier over. En ik heb ook al even wat zitten experimenteren met c#, maar op dit moment vind ik Nice toch even wat leuker

oja... wat vinden jullie van unprotected mode in .NET?

[whoami]

Alarmnummer schreef op 18 oktober 2002 @ 11:57:
Een taal is een vervoersmiddel en niet een doel, als zich iets beters voordoet dan stap ik met veel plezier over.

Helemaal gelijk.

En ik heb ook al even wat zitten experimenteren met c#, maar op dit moment vind ik Nice toch even wat leuker

Hier spreek je jezelf toch een beetje tegen... Je gebruikt nice omdat je het leuker vind, niet omdat het een beter hulpmiddel is om jouw doel te bereiken.

oja... wat vinden jullie van unprotected mode in .NET?

Nog niet mee gespeeld. Ik heb er eigenlijk ook nog geen behoefte aan gehad om unprotected code te gebruiken. (Ik zie er eigenlijk niet echt het voordeel van in. OK, je kunt dan wel pointers enzo gaan gebruiken, maar in managed mode heb je toch ook reference types).

[curry684]

Alarmnummer schreef op 18 oktober 2002 @ 11:09:
Het is ook zeker niet een verplichte oo feature, maar het wordt een stuk lastiger als je het niet kan gebruiken En verder beschouwen jullie multiple inheritance als iets dat moet gebeuren van een class, en dat hoeft zeker niet. Classes en Interfaces zijn allemaal types en je kan dus een nieuw type maken op basis van meerdere types, en is Java in mijn ogen ook een multiple inheritance taal *weet dat het wel vrij ongebruikelijk is om er zo over te praten in de oo wereld dus ik begrijp ook zeker wat jullie bedoelen*

De grootste problemen van true multiple inheritance en waarom de meeste talen het niet ondersteunen:
• Welke constructors en virtual destructors worden in welke volgorde wanneer aangeroepen?
• Ambiguities... wat als een method/property meerdere keren bestaat in de inheritances?
• Heel erg: wat te doen bij een 'ruitje', dwz. D extends C and B, C and B extend A....
• Virtual base classes maken helemaal een rotzooi van je vtable en verneuken daardoor je interface pointers waardoor je met inner/outer classes moet gaan werken.

Allemaal heel erg tricky spul om te managen, en daarom is er in de meeste talen voor gekozen om het hele goedje simpelweg overboord te flikkeren en alleen multiple inheritance toe te staan dmv interfaces, want:
• EEN base class constructor
• EEN base class destructor
• Geen method implementation ambiguities want er zijn geen meedere implementaties
• Geen dubbele properties waardoor je op de verkeerde werkt
• Geen ruitjes mogelijk
• Simpele 'vtables'

Hierdoor zijn Java en C# dus echt wel single-inheritance talen, en heeft multiple interface inheritance echt wel wat andere gevolgen dan full class inheritance.

[curry684]

Genoil schreef op 18 oktober 2002 @ 11:38:

offtopic:
zou het komen dat de forumpolitie denkt dat het niveau in /14 daalt vanweg het feit dat hoogdravende discussies over multiple inherintance terecht komen in [PHP] topics ?

Zelfs ik reageer voor de eerste keer in 1000+ posts buiten een C++ topic en in een PHP-topic

[curry684]

Genoil schreef op 18 oktober 2002 @ 10:34:
Euhm...say whaaat?!? Wie houdt mij tegen:
1. ikzelf? dit is toch wel een kilometer boven mijn pet

Mwah, misschien dat ik het in andere bewoordingen beter kan uitleggen

2. de klant? hij heeft al een 'heavyweight' CMS monster in J2EE door een andere partij laten ontwikkelen en waardeert ons juist om de eenvoud van onze ontwerpen.

Hier hoeft helemaal niets moeilijk of heavyweight aan te zijn, gewoon een lijstje van ActiveSessions.

3. PHP(-CGI) op klant z'n SGI servert? Leg me anders eens uit hoe je bovenstaande met PHP ISAPI doet? Klinkt wel doop

Geen idee, ik ken geen PHP Ik mag toch echter hopen dat je global objecten aan kunt maken die een langere life-cycle hebben dan 1 HTML-request... zo ja ben je al bijna klaar. Kun je ook unattended monitor threads in PHP bouwen trouwens?

[whoami]

curry684 schreef op 18 oktober 2002 @ 12:03:
[...]

• Ambiguities... wat als een method/property meerdere keren bestaat in de inheritances?

IMHO is het dan gewoon de taak van de programmeur om ervoor te zorgen dat de goede/juiste method aangeroepen wordt. De compiler moet dan toch gewoon een error geven? Zoals dat nu in C++ gebeurt. (Of heb ik jouw opmerking verkeerd begrepen?).

[smaij]

curry684 schreef op 18 oktober 2002 @ 12:12:
Geen idee, ik ken geen PHP Ik mag toch echter hopen dat je global objecten aan kunt maken die een langere life-cycle hebben dan 1 HTML-request... zo ja ben je al bijna klaar. Kun je ook unattended monitor threads in PHP bouwen trouwens?

Volgens mij zou je dan toch sessies moeten gebruiken met misschien een combinatie met een database.

[Genoil]

curry684 schreef op 18 oktober 2002 @ 12:12:
[...]

Mwah, misschien dat ik het in andere bewoordingen beter kan uitleggen

[...]

Hier hoeft helemaal niets moeilijk of heavyweight aan te zijn, gewoon een lijstje van ActiveSessions.

[...]

De enige informatie die een PHP proces (ik noem het expliciet proces, geen applicatie) kent over sessies, is een array-variabele $_SESSION, waarin slechts de sessievariabelen van het proces zelf staan, toegang tot alle sessies heb je niet.

Geen idee, ik ken geen PHP Ik mag toch echter hopen dat je global objecten aan kunt maken die een langere life-cycle hebben dan 1 HTML-request... zo ja ben je al bijna klaar. Kun je ook unattended monitor threads in PHP bouwen trouwens?

Nee bij mijn weten kan dat niet met PHP, en gaat dat in de toekomst ook niet kunnen met PHP. De taal is denk ik ook niet bedoeld voor dit soort dingen, dan kun je beter C++ of J2EE gebruiken.

PHP heeft evenmin threads, dus zo'n "unattended monitor thread" (wat dat ook moge zijn) zal vast niet tot de mogelijkheden behoren...

Maakt dit mij argument tegen PHP-OOP sterker?

[ Voor 0% gewijzigd door Genoil op 18-10-2002 13:18 . Reden: beetje gegoogled en dus wat antwoorden gevonden ]

[curry684]

Genoil schreef op 18 oktober 2002 @ 13:06:
De enige informatie die een PHP proces (ik noem het expliciet proces, geen applicatie) kent over sessies, is een array-variabele $_SESSION, waarin slechts de sessievariabelen van het proces zelf staan, toegang tot alle sessies heb je niet.

Je hebt toch cookies? En wat bedoel je met 'sessievariabelen van het proces zelf', welke scope heeft dat en wat kun je erin kwijt?

Nee bij mijn weten kan dat niet met PHP, en gaat dat in de toekomst ook niet kunnen met PHP. De taal is denk ik ook niet bedoeld voor dit soort dingen, dan kun je beter C++ of J2EE gebruiken.

Open vraag: hoe onthoudt React dat ik sinds 13:57:29 ingelogd ben? Hij moet dit *of* in een cookie opslaan dat iedere keer meegaat, *of* in de database fietsen waar ie het iedere request uittrekt, *of* in een globale variabele frotten. Wie weet?

[smaij]

curry684 schreef op 18 oktober 2002 @ 14:25:
Open vraag: hoe onthoudt React dat ik sinds 13:57:29 ingelogd ben? Hij moet dit *of* in een cookie opslaan dat iedere keer meegaat, *of* in de database fietsen waar ie het iedere request uittrekt, *of* in een globale variabele frotten. Wie weet?

zodra jij je window sluit ben je uitgelogd (geen actieve sessie meer) maar geen nood, je hebt een cookie op je computer en er staat wat informatie over jouw cookie en computer in de database (ip adres lijkt me logisch?)

zodra jij weer gaat GoT-en komt ie erachter dat er geen sessie is, kijkt ie of ie een cookie vind, zoja logged jouw opnieuw in en zet in de cookie sinds wanneer je bent ingelogd, zodat de cookie weer 'blijft' leven, zolang jij (of React) kiest en niet verwijderd.

zoiets?

[Genoil]

curry684 schreef op 18 oktober 2002 @ 14:25:
[...]

Je hebt toch cookies? En wat bedoel je met 'sessievariabelen van het proces zelf', welke scope heeft dat en wat kun je erin kwijt?

Ehm ja jij zei iets in de trant van "houd een lijstje bij met actieve sessies", maar de scope van $_SESSION reikt niet verder dan 1 sessie, dus zo'n lijstje bijhouden is in PHP niet mogelijk.

Je kunt er wel vanalles in kwijt, tot objecten aan toe. Maar de vraag is, is dat echt persistent? De objecten worden immers geserialized en weer terug. Kan me herinneren dat ik hier vorig jaar ook gezeik mee kreeg op een gegeven moment, maar dat ga ik zo nog ff proberen (= toch vrijdagmiddag)

[curry684]

smaij schreef op 18 oktober 2002 @ 14:31:
zodra jij je window sluit ben je uitgelogd (geen actieve sessie meer) maar geen nood, je hebt een cookie op je computer en er staat wat informatie over jouw cookie en computer in de database (ip adres lijkt me logisch?)

zodra jij weer gaat GoT-en komt ie erachter dat er geen sessie is, kijkt ie of ie een cookie vind, zoja logged jouw opnieuw in en zet in de cookie sinds wanneer je bent ingelogd, zodat de cookie weer 'blijft' leven, zolang jij (of React) kiest en niet verwijderd.

Je had mogen volstaan met als antwoord 'dat doet React met cookie', de specifieke details van hoe een cookie werkt kan ik ook wel invullen

Weet je het trouwens zeker? Want een cookie heeft als nadeel dat het client-pushed is, ergo heel leuk voor automatisch inloggen en gerelateerde nonsens maar redelijk 100% onbruikbaar om sessiebeheer mee te doen daar je de cookie niet krijgt als de browser sluit. Hiervoor zul je dus een OnClose method moeten regelen, deze kan echter weer niet aan je cookies op de clientbak... dus hoe doet ie dat?

* curry684 is gewoon eens onschuldig aan het vissen puur om de technische weetjes, verder niet de minste interesse in PHP of forumcoding...

[curry684]

Genoil schreef op 18 oktober 2002 @ 13:06:
Maakt dit mij argument tegen PHP-OOP sterker?

Op basis van de geleverde informatie zou ik op dit moment voor een C++ ISAPI-extension gaan

[Genoil]

curry684 schreef op 18 oktober 2002 @ 17:04:
[...]

Op basis van de geleverde informatie zou ik op dit moment voor een C++ ISAPI-extension gaan

Tsja ik ben nu even bezig met het opslaan van een eenvoudig hierarchisch node-structuurtje in een sessie, en probeer aan een dieper liggende node na elke refresh iets te veranderen. Dat lukt me dus gewoon (nog) niet! Maar daar open ik wel ff een ander topic voor...

[Genoil]

nja dat ander topic komt misschien maandag dan wel , weekend vieren is momenteel ff belangrijker dan het probleem waar ik mee zit: Hoe verkrijg ik een referentie naar een object in m'n hierarchie in plaats van dattie er een kopie van maakt? De enige manier hoe ik het nu enigszins werkend krijg, is wanneer ik een subnode onder node hang (by reference), zowel de subnode als de hierarchie apart in de sessie op te slaan. En dat gaat natuurlijk helemaal nergens over! Ik vrees dat het antwoord ZE2 is , maar ik post maandag m'n code nog wel ff...