[php] OOP, hoever ga je?

[Slagroom]

Hallo,

Ik ben sinds kort bezig om mezelf helemaal OOP (noob ;-)) te maken. Tenminste, dat probeer ik.

Nu vroeg ik mij af hoever je moet gaan met OOP. Moet zoveel mogelijk OOP?

Bijvoorbeeld een configuratie bestand. Dat kan er zo uit zien:
Niet OOP:

PHP:

<?php
$_CONFIG = array ();
$_CONFIG['database'] = array ();
$_CONFIG['database']['host'] = 'localhost';
$_CONFIG['database']['name'] = 'databeestje';
$_CONFIG['database']['user'] = 'root';
$_CONFIG['database']['pass'] = 'tsja';
?>

Maar ook zo:
Wel OOP:

PHP:

<?php
class Config {
    var $database_user;
    var $database_pass;
    var enz...

    function Config () {
        $this->database_user = 'root';
        $this->database_pass = 'tsja';
        $this->enz...
    }
}
?>

Beide is netjes vindt ik maar wat is nou handig, verstandig, enz?

[Verwijderd]

Meh.

Als het maar over statische gegevens gaat, is OOP niet overdreven nuttig. Het is een kwestie van smaak hier denk ik, of je arrays of "records-met-een-vanille-smaakje" wilt gebruiken.

De kracht van OOP zit 'm er niet in om dingen anders op te schrijven...

[Slagroom]

Vindt ik ook maar ik heb het nu meerdere malen gezien maar ik vond dit toch iets te ver gaan.

[Verwijderd]

Slagroom schreef op 28 juli 2004 @ 11:32:
Vindt ik ook maar ik heb het nu meerdere malen gezien maar ik vond dit toch iets te ver gaan.

Wat bereik je volgens jou met de methode om van config een object te maken?

[PrisonerOfPain]

Je kan zo ver gaan als je wilt, maar om hier een class voor te maken is een beetje overbodig vind ik. Daarbij zou ik het (als ik een class zou gebruiken) het ongeveer zo doen

PHP:

<?php

class Config
{
    var $Database;

    function Config()
    {
        $this->Database = new Database_Config();
    }
}

class Database_Config
{
    var $Username;
    var $Password;
    var $Host;
}

$Config = new Config();
$Config->Database->Username = "root";
//enzo
?>

En er eventueel nog een singleton van maken, je hebt immers maar een configruatie nodig

[alienfruit]

Ik heb alleen Config klasse in PHP om Web.Config stijl xml bestanden in te lezen

[Bosmonster]

Als je aan je config ook bijvoorbeeld methodes wilt verwerken die extern een config laden, of een default config terugzetten etc, dan heeft een object toegevoegde waarde. Of als je meerdere verschillende configuraties wilt kunnen bijhouden en switchen. Als het alleen maar een verzameling gegevens blijft is het nogal overbodig.

[ Voor 15% gewijzigd door Bosmonster op 28-07-2004 11:52 ]

[Zoijar]

Bosmonster schreef op 28 juli 2004 @ 11:51:
Als je aan je config ook bijvoorbeeld methodes wilt verwerken die extern een config laden, of een default config terugzetten etc, dan heeft een object toegevoegde waarde. Of als je meerdere verschillende configuraties wilt kunnen bijhouden en switchen. Als het alleen maar een verzameling gegevens blijft is het nogal overbodig.

Misschien is het nu alleen een verzameling gegevens, maar wil je later het toch ineens uit een (remote?) xml file halen. Een class is dus altijd handig. Het gaat niet alleen om nu, maar ook om later.

[Verwijderd]

Zoijar schreef op 28 juli 2004 @ 12:11:
[...]

Misschien is het nu alleen een verzameling gegevens, maar wil je later het toch ineens uit een (remote?) xml file halen. Een class is dus altijd handig. Het gaat niet alleen om nu, maar ook om later.

Juist, in je "echte" code (de applicatie dus) hoef je dan weinig tot geen code aan te passen, terwijl je in je class vrolijk kan prutsen

[Zoijar]

Verwijderd schreef op 28 juli 2004 @ 12:14:
Juist, in je "echte" code (de applicatie dus) hoef je dan weinig tot geen code aan te passen, terwijl je in je class vrolijk kan prutsen

Psies Of iemand anders die jouw code gebruikt kan inheritance van die class gebruiken om de config anders te maken. Dan hoeft een derde (of de programmeur die in dienst wordt genomen nadat jij bent ontslagen ) helemaal niet in jouw code te gaan zitten prutsen.

[Slagroom]

Nu heeft mij het argument om een andere source te gebruiken overgehaald om een Conifg class te gebruiken.

Wat is een nette manier op een variabele uit de config op te halen?

Dit:
$config->database['host']
Of:
$config->getValue ('database_host');

De bovenste is makkelijker en sneller toe te passen maar de onderste lijkt me netter... hmmm zegt u het eens.

[curry684]

Bosmonster schreef op 28 juli 2004 @ 11:51:
Als je aan je config ook bijvoorbeeld methodes wilt verwerken die extern een config laden, of een default config terugzetten etc, dan heeft een object toegevoegde waarde. Of als je meerdere verschillende configuraties wilt kunnen bijhouden en switchen. Als het alleen maar een verzameling gegevens blijft is het nogal overbodig.

Of zoals we dat in de volwassen OOP-talen noemen: het verschil tussen een struct en een class

[Zoijar]

Slagroom schreef op 28 juli 2004 @ 12:38:
Wat is een nette manier op een variabele uit de config op te halen?

De onderste. Altijd een accessor functie gebruiken, die kan iemand anders dan namelijk later nog overloaden, of jij kan er dingen aan toevoegen etc. Als je rechtstreeks data members kan aanspreken heb je weinig voordeel. Data members zijn altijd private, behalve als ... (lijst met uitzonderingen)

[Verwijderd]

curry684 schreef op 28 juli 2004 @ 12:45:
[...]

Of zoals we dat in de volwassen OOP-talen noemen: het verschil tussen een struct en een class

Welnee, een record en een class. Pascal forever .

[curry684]

Zoijar schreef op 28 juli 2004 @ 12:48:
[...]

De onderste. Altijd een accessor functie gebruiken, die kan iemand anders dan namelijk later nog overloaden, of jij kan er dingen aan toevoegen etc. Als je rechtstreeks data members kan aanspreken heb je weinig voordeel. Data members zijn altijd private, behalve als ... (lijst met uitzonderingen)

Voor de absolute OOP-purist is daar geen lijst van uitzonderingen, al is het maar omdat je door geen getters/setters te definieren in de toekomst geen extra functionaliteit aan de get of set toe kunt voegen.

[PrisonerOfPain]

curry684 schreef op 28 juli 2004 @ 12:45:
[...]

Of zoals we dat in de volwassen OOP-talen noemen: het verschil tussen een struct en een class

Aangezien PHP geen structs heeft zul je ze "moeten" faken d.m.v. classes als je het op een dergelijke manier wilt doen.

[Verwijderd]

Persoonlijk vind ik getters en setters vies. Properties daarentegen...

[curry684]

Verwijderd schreef op 28 juli 2004 @ 12:52:
Persoonlijk vind ik getters en setters vies. Properties daarentegen...

En wat is een Property in Delphi/C#/BCB meer dan een encapsulatie van een getter en/of setter?

[KompjoeFriek]

Verwijderd schreef op 28 juli 2004 @ 12:52:
Persoonlijk vind ik getters en setters vies. Properties daarentegen...

Ik vind het juist andersom

bij getters/setters kun je nog controles in de class zelf zetten, als je de property rechtstreeks binnen haalt, en toch ergens een controle op wilt hebben, zul je dat buiten de class zetten, en misschien zelfs onnodig herhalen

edit:
Als je geen controles gebruikt/nodig hebt, kun je net zo goed de property direct aanspreken. getters/setters hebben dan geen meerwaarde. Maar ik zou, als ik dan toch ergens getters/setters gebruik, het overal gebruiken. om de code consistent te houden
(is wel heel algemeen over OO, niet specifiek voor php)

[ Voor 28% gewijzigd door KompjoeFriek op 28-07-2004 13:00 ]

[wica]

Je kan je config toch in een Object zetten?

PHP:

class Object{}
$config=new Object();
$config->host="localhost"
$config->db="test"

Moet er wel bij zeggen dat ik dit ben gebruiken. Om het programmeren in Flash ActionScript2 en php een beetje gelijk te trekken

[Verwijderd]

KompjoeFriek schreef op 28 juli 2004 @ 12:56:
[...]
Ik vind het juist andersom

bij getters/setters kun je nog controles in de class zelf zetten, als je de property rechtstreeks binnen haalt, en toch ergens een controle op wilt hebben, zul je dat buiten de class zetten, en misschien zelfs onnodig herhalen

edit:
Als je geen controles gebruikt/nodig hebt, kun je net zo goed de property direct aanspreken. getters/setters hebben dan geen meerwaarde. Maar ik zou, als ik dan toch ergens getters/setters gebruik, het overal gebruiken. om de code consistent te houden
(is wel heel algemeen over OO, niet specifiek voor php)

Ik bedoel properties zoals ze bestaan in Delphi en C#: geïmpliceerde getters en setters. Dwz, als je een property aanspreekt KAN het zo zijn dat je direct een geheugenadres aanspreekt, of dat er op de achtergrond een functie aangeroepen wordt. Als gebruiker van de klasse hoef je dat echter niet te weten; je hoeft alleen te weten wat de property betekent, en dat je er van kan lezen en naar kan schrijven als je 'm aan wil passen, en dat alles automatisch goed komt.

[Zoijar]

curry684 schreef op 28 juli 2004 @ 12:50:
Voor de absolute OOP-purist is daar geen lijst van uitzonderingen, al is het maar omdat je door geen getters/setters te definieren in de toekomst geen extra functionaliteit aan de get of set toe kunt voegen.

Zit wel wat in ja. Ik heb ook zelfs in mijn vector classes nu get en set voor coordinaten. Met inlines heb je toch geen performance verlies. (@oneofborg Zie trouwens niet het verschil tussen dit en properties, maar misschien mis ik iets)

[alienfruit]

Hmm. Waarom zou je records ondersteuning willen hebben in PHP? Het is toch al in het beginsel brak, zie er ook niet veel nut voor in PHP. Behalve dat je strucuteren beter kan opslaan, maar ja je kunt toch niks langer bewaren dan de duur van de request in PHP.

[Verwijderd]

Zoijar schreef op 28 juli 2004 @ 13:20:
[...]

Zit wel wat in ja. Ik heb ook zelfs in mijn vector classes nu get en set voor coordinaten. Met inlines heb je toch geen performance verlies. (@oneofborg Zie trouwens niet het verschil tussen dit en properties, maar misschien mis ik iets)

Inlines zijn de oplossing voor een probleem dat je niet zou hebben met properties.

En het verschil zit mij 'm in de syntax. Die is "natuurlijker" met properties. Maar omdat iedereen gewend is de C++ dinosaurus te gebruiken, en zijn neefje Java, zie je getters en setters veel vaker, en raak je daar aan gewend. En dan lijkt dat natuurlijker/logischer.

Dit is natuurlijk allemaal slechts im(ns)ho .

[ Voor 5% gewijzigd door Verwijderd op 28-07-2004 13:31 ]

[PrisonerOfPain]

Zoijar schreef op 28 juli 2004 @ 13:20:
[...]

Zit wel wat in ja. Ik heb ook zelfs in mijn vector classes nu get en set voor coordinaten. Met inlines heb je toch geen performance verlies. (@oneofborg Zie trouwens niet het verschil tussen dit en properties, maar misschien mis ik iets)

Een propertie roep je aan als een variabele, dus Instance.Value = "iets"; maar kan een 'functie' zijn die het e.e.a. aan validatie afhandeld. Zoiets heeft PHP trouwens ook met de __get en __set functies, maar die gelden voor alle variabelen waar C# properties per variabele veschillend zijn

In C# zijn properties ongeveer op de volgende manier geimplementeerd

code:

public int ErrorCode
{
      get
      {
            return ErrorCode;
      }
}

Terwijl je in PHP het volgende zou doen

PHP:

public function __get ($name, &$value)
{
      switch ($name)
      {
            case 'ErrorCode':
                  $value = $this->ErrorCode;
                  return true;
                  break;
            default:
                  return false;
      }
}

overload ($Instance);

[ Voor 4% gewijzigd door PrisonerOfPain op 28-07-2004 13:32 ]

[Verwijderd]

niet geheel onbelangrijk, hebben we het hier over PHP 4 of PHP 5? ,php5 objecten zijn namelijk nogal anders dan php 4 objecten (lees: veel beter imho) zie http://www.zend.com/manual/migration5.oop.php

[alienfruit]

Veel beter? Iets beter zul je bedoelen, het is toch steeds brak. Zie bijv. die __get/__set opmerking hierboven. Als je zoiets implementeert doe het dan meteen goed

[PrisonerOfPain]

alienfruit schreef op 28 juli 2004 @ 13:57:
Veel beter? Iets beter zul je bedoelen, het is toch steeds brak. Zie bijv. die __get/__set opmerking hierboven. Als je zoiets implementeert doe het dan meteen goed

Dat zit er al sinds versie 4 in hoor en ja het is beter als het OOP model in PHP4 maar om nou van een ware revolutie te spreken. Helaas, ik stap geleidelijk over op C#.

[djluc]

IMO:
gebruik je voor een configuratie gestand gewoon een standaard methode, denk aan een INI of een XML bestand, Een class is dan handig om het inlezen van een dergelijk bestand te standaardiseren.

Dit voorbeeldje:

PHP:

<?php
class Config {
    var $database_user;
    var $database_pass;
    var enz...

    function Config () {
        $this->database_user = 'root';
        $this->database_pass = 'tsja';
        $this->enz...
    }
}
?> 

is imo gewoon onzin. Een class gebruiken zorgt voor overzicht en herbruikbaarheid, zoek de fouten

Voor performance kan het wel handig zijn om een ini-bestand niet iedere keer te parsen, maar alleen even de verschillen te controleren met bijvoorbeeld een MD5. De geparste versie kan je als cache opslaan in een bestandje in bijvoorbeeld een array zoals in de startpost is aangegeven. Het inlezen hiervan is waarschijnlijk sneller dan een bestand parsen.

[curry684]

PrisonerOfPain schreef op 28 juli 2004 @ 14:45:
[...]

Dat zit er al sinds versie 4 in hoor en ja het is beter als het OOP model in PHP4 maar om nou van een ware revolutie te spreken. Helaas, ik stap geleidelijk over op C#.

* curry684 krijgt ineens een herinnering aan deze magistrale quote

[Verwijderd]

Verwijderd schreef op 28 juli 2004 @ 13:31:
Inlines zijn de oplossing voor een probleem dat je niet zou hebben met properties.

Ehh, dat je een getter/setter niet expliciet hoeft te definiëren heeft niks te maken met het al dan niet inlinen van zo'n getter/setter.

En het verschil zit mij 'm in de syntax. Die is "natuurlijker" met properties.

Syntactic sugar dus. Een property kan niets meer dan een getter/setter, het oogt wat leuker omdat je geen haakjes achter een property hoeft te gebruiken, maar daarmee is ook alles gezegd.

Maar omdat iedereen gewend is de C++ dinosaurus te gebruiken, en zijn neefje Java

Vlam vlam. Kom eens terug tegen de tijd dat C# en Delphi evenveel funtionaliteit in de taal biedt als C++ (templates, multiple inheritance).

[PrisonerOfPain]

Verwijderd schreef op 28 juli 2004 @ 15:01:
Syntactic sugar dus. Een property kan niets meer dan een getter/setter, het oogt wat leuker omdat je geen haakjes achter een property hoeft te gebruiken, maar daarmee is ook alles gezegd.

Je draait het om, een method definieerd nogsteeds het gedrag maar niet de eigenschappen van een class. Vandaar de properies

Vlam vlam. Kom eens terug tegen de tijd dat C# en Delphi evenveel funtionaliteit in de taal biedt als C++ (templates, multiple inheritance).

http://research.microsoft.com/projects/clrgen/ (okee, generisc zijn geen templates )

[Janoz]

Verwijderd schreef op 28 juli 2004 @ 13:31:

En het verschil zit mij 'm in de syntax. Die is "natuurlijker" met properties.

Mwah, persoonlijk zie ik liever gelijk wat ik nu eigenlijk doe. Nu weet ik niet precies hoe properties geimplementeerd zijn, maar ik voorzie problemen bij het aanroepen van een getter binnen de eigen class.

Eigenlijk komt het er op neer dat exact hetzelfde stukje code verschillend kan werken afhankelijk van de plaats waar deze staat (Andere class, zelfde class, binnen de setter/getter zelf) en dat vind ik dan onduidelijk. Nee, geef mij maar code waaraan ik precies zie wat wordt aangeroepen .

[alienfruit]

Vlam vlam. Kom eens terug tegen de tijd dat C# en Delphi evenveel funtionaliteit in de taal biedt als C++ (templates, multiple inheritance).

Hoezo Delphi ondersteunt al multiple inheritance, en het gaat generics ondersteunen net zoals C#. Zelf nooit begrepen waarom je templates wilt gebruiken, overigens. Maakt je code niet leesbaarder

[Zoijar]

Verwijderd schreef op 28 juli 2004 @ 13:31:
En het verschil zit mij 'm in de syntax. Die is "natuurlijker" met properties. Maar omdat iedereen gewend is de C++ dinosaurus te gebruiken, en zijn neefje Java, zie je getters en setters veel vaker, en raak je daar aan gewend. En dan lijkt dat natuurlijker/logischer.

Tsja, misschien is het persoonlijke voorkeur. Ik hou niet zo van dingen die automagically gebeuren. Met get/set worden beiden mogelijkheden apart geboden, de programmeur maakt de beslissing (of die nou goed is of slecht is een tweede) en niet de taal. Een taal moet een hulpmiddel zijn om een probleem uit te drukken. De taal moet dus niet allemaal dingen aan nemen en met een beetje magie voor elkaar krijgen.

Ik weet niets van properties helaas, maar kunnen die side effects hebben? Zal haast wel, lastig om daar op te checken namelijk. Dan doet "obj.x = 1; obj.x = 1;" ineens iets anders dan "obj.x = 1;". Dat verwacht je niet, want je denk gewoon een geheugen var te zetten. Met de functie haakjes zie je in ieder geval dat er een functie wordt aangeroepen met mogelijke side effects. (ofwel "obj.x() = 1", of "obj.x(1);" wederom nog eens twee mogelijkheden om de dingen te doen)

Oh en...
Je kan C++ templates niet vergelijken met van die generics dingen. C++ templates bieden een turing complete compile time taal!

Janoz schreef op 28 juli 2004 @ 15:27:
Zodra je een keer een lijst geschreven hebt voor 1 type en je hebt exact dezelfde lijst nodig voor een ander type zie je de voordelen van templates vast wel in.

In feite zijn dat generics, templates worden meestal als iets brder begrip gezien. Maar je hebt wel gelijk natuurlijk als je dat onderscheid niet maakt.

alienfruit schreef op 28 juli 2004 @ 15:29:
Naja, dan vind ik zelf toch nog dat Search-And-Replace fijner :-)

Troll?

[ Voor 32% gewijzigd door Zoijar op 28-07-2004 15:31 ]

[Janoz]

alienfruit schreef op 28 juli 2004 @ 15:20:
[...]
Zelf nooit begrepen waarom je templates wilt gebruiken, overigens. Maakt je code niet leesbaarder

Zodra je een keer een lijst geschreven hebt voor 1 type en je hebt exact dezelfde lijst nodig voor een ander type zie je de voordelen van templates vast wel in.

Zelf vindt ik
List list = new List()
....
Integer value =list.get(index);

leesbaarder dan
List list = new List()
....
Integer value =(Integer)list.get(index);


@Zoijar : Ik geef een reden waarom templates/generics handig zijn, niet de reden .. Ben zelf voornamelijk java programmeur en mis ze wel.

[ Voor 33% gewijzigd door Janoz op 28-07-2004 15:33 ]

[alienfruit]

Naja, dan vind ik zelf toch nog dat Search-And-Replace fijner :-)

[Janoz]

alienfruit schreef op 28 juli 2004 @ 15:29:
Naja, dan vind ik zelf toch nog dat Search-And-Replace fijner :-)

Todat je drie handige nieuwe methodes toe wilt voegen aan je List class waarvan je mbv SnR ondertussen al 20 verschillende types hebt liggen...

[curry684]

alienfruit schreef op 28 juli 2004 @ 15:20:
[...]


Hoezo Delphi ondersteunt al multiple inheritance, en het gaat generics ondersteunen net zoals C#. Zelf nooit begrepen waarom je templates wilt gebruiken, overigens. Maakt je code niet leesbaarder

C++ gaat dan ook niet over leesbaarheid, maar over kracht. Wat exact de reden is waarom templates in 'lesser languages' niet geimplementeerd wordt: het komt de leesbaarheid niet ten goede nee. De snelheid en kwaliteit van je code wel, en dat is nu net de USP van C++.

[PrisonerOfPain]

Zoijar schreef op 28 juli 2004 @ 15:21:
[...]
Ik weet niets van properties helaas, maar kunnen die side effects hebben?

Ja, net zo goed als een method dat kan hebben. Dus dat is het punt helemaal niet. Met een propertie geef je een eigenschap aan van een class (kleur ofzo) die je kan valideren wat je met een setter net zo goed doet, maar omdat je een methode gebruikt impliceer je dat het een gedrag is van die class.

Oh en...
Je kan C++ templates niet vergelijken met van die generics dingen. C++ templates bieden een turing complete compile time taal!

Weet ik, maar het idee er achter (operaties op objecten uitvoeren onafhankelijk van het type) is grotendeels hetzelfde

[Verwijderd]

Yayy, laten we er een flame/discussietopic van maken.

Het is vooral een discussie over smaak, dus eruit komen of iemand overtuigen zal toch niet lukken, magoed, for what it's worth:

Verwijderd schreef op 28 juli 2004 @ 15:01:
[...]
Ehh, dat je een getter/setter niet expliciet hoeft te definiëren heeft niks te maken met het al dan niet inlinen van zo'n getter/setter.

Qué? Nee klopt. Maar waarom zit dat inlinen er? Omdat je voor een getter (die vaak gewoon de waarde van een variabele teruggeeft) anders elke keer een functiecall nodig hebt. Dus begint iedereen uit het efficiency-kamp (en dat is bij C++ zo'n beetje iedereen ) meteen te schreeuwen: "Ja maar eej, dat gebruiken we niet, daar wordt de code veel te traag van!". En dus geven ze je de mogelijkheid om er inlines van te maken, zodat het nadeel dat de getters opgeroepen hebben weer onder het tapijt geveegd kan worden. Erg leuk ook overigens, dat je de code dan in de declaratie van de klasse moet zetten. Implementation hiding, mehoela.

Syntactic sugar dus. Een property kan niets meer dan een getter/setter, het oogt wat leuker omdat je geen haakjes achter een property hoeft te gebruiken, maar daarmee is ook alles gezegd.

Niet helemaal. Omdat je een property voor het lezen of schrijven ook direct naar een geheugenadres kan laten verwijzen, heb je geen geinlinede getter nodig. Verder kun je op heel natuurlijke wijze de waarde van een "eigenschap" uitlezen danwel veranderen.

code:

print willy.length
willy.length := willy.length * 2

versus

code:

print willy.getLength()
willy.setLength(willy.getLength() * 2)

Tuurlijk, het tweede is ook wel te schrijven/lezen, maar het eerste is makkelijker en oogt duidelijker.

Vlam vlam. Kom eens terug tegen de tijd dat C# en Delphi evenveel funtionaliteit in de taal biedt als C++ (templates, multiple inheritance).

Leuke Red Herring, maar daar ging 't niet over, wel?

Ik wil er nog wel even op ingaan: ik vind het inderdaad jammer dat Delphi geen generics bezit; al dat typecasten bij het gebruik van een TList wordt op den duur nogal vervelend. En multiple inheritance... sja. Dat is weer een hele discussie op zich. Persoonlijk vind ik dat multiple inheritance wel moet kunnen, maar echt missen doe ik 't niet. En het is natuurlijk altijd te simuleren met interfaces.

PrisonerOfPain schreef op 28 juli 2004 @ 15:17:
(okee, generisc zijn geen templates )

Templates zijn een implementatie van generics, of beter gezegd Generic Programming.

Janoz schreef op 28 juli 2004 @ 15:17:
[...]
Mwah, persoonlijk zie ik liever gelijk wat ik nu eigenlijk doe. Nu weet ik niet precies hoe properties geimplementeerd zijn, maar ik voorzie problemen bij het aanroepen van een getter binnen de eigen class.

Eigenlijk komt het er op neer dat exact hetzelfde stukje code verschillend kan werken afhankelijk van de plaats waar deze staat (Andere class, zelfde class, binnen de setter/getter zelf) en dat vind ik dan onduidelijk. Nee, geef mij maar code waaraan ik precies zie wat wordt aangeroepen .

Ik ben bang dat ik niet begrijp wat je bedoelt. Als je het goed implementeert zorg je natuurlijk dat een stuk code maar één betekenis heeft. En dan nog liefst eentje die consistent is door je hele codebase.

Zoijar schreef op 28 juli 2004 @ 15:21:
[...]
Tsja, misschien is het persoonlijke voorkeur. Ik hou niet zo van dingen die automagically gebeuren. Met get/set worden beiden mogelijkheden apart geboden, de programmeur maakt de beslissing (of die nou goed is of slecht is een tweede) en niet de taal. Een taal moet een hulpmiddel zijn om een probleem uit te drukken. De taal moet dus niet allemaal dingen aan nemen en met een beetje magie voor elkaar krijgen.

Niets houdt je tegen om in Delphi of C#, of welke taal dan ook properties ondersteunt, gewoon nog steeds getter- en setterfuncties te maken hoor.

Ik weet niets van properties helaas, maar kunnen die side effects hebben? Zal haast wel, lastig om daar op te checken namelijk. Dan doet "obj.x = 1; obj.x = 1;" ineens iets anders dan "obj.x = 1;". Dat verwacht je niet, want je denk gewoon een geheugen var te zetten. Met de functie haakjes zie je in ieder geval dat er een functie wordt aangeroepen met mogelijke side effects. (ofwel "obj.x() = 1", of "obj.x(1);" wederom nog eens twee mogelijkheden om de dingen te doen)

Dat kán ja. Maar als je obj.setX(1); obj.setX(1); doet verwacht je ook niet dat er twee dingen gebeuren. Het punt is dat als je je (verborgen) setter goed implementeert, het stuk code doet wat je verwacht. De discussie is niet of het te misbruiken is, of dat er slechte code mee geschreven kan worden. Natuurlijk, maar dat kan zonder properties even goed. Properties zijn echter wel een manier om je code een stuk leesbaarder mee te maken.

Overigens heb ik hier al vaker (vruchteloos) over gediscussiëerd met sterf-harde C++ programmeurs, en ik verwacht dan ook niet jullie te overtuigen.

(Maar ik probeer 't toch )

[Zoijar]

Verwijderd schreef op 28 juli 2004 @ 15:40:
Overigens heb ik hier al vaker (vruchteloos) over gediscussiëerd met sterf-harde C++ programmeurs, en ik verwacht dan ook niet jullie te overtuigen.

(Maar ik probeer 't toch )

Nouja, mij hoef je niet te overtuigen. Als ik het me goed herinner was jij degene die get/set maar niks vond, en properties het einde. En daarbij nog even C++ als dinosaurus noemde. Ik (en anderen) zeiden alleen even dat get/set eigenlijk hetzelfde is, en toen verdedigde ik nog even mijn favorite taal die objectief gezien nog steeds geen gelijke kent

[Verwijderd]

Ik heb daar ook bijgezegd dat dat slechts mijn mening was. Ik ben inderdaad geen fan van C en C++, maar misschien is dat omdat ik groot ben geworden met Pascal (en pindakaas). Overigens is dat iets waar ik al helemáál geen discussie over wil starten .

offtopic:
En ik snap nu je usertitle

[curry684]

Zoijar schreef op 28 juli 2004 @ 15:21:
[...]

Ik weet niets van properties helaas, maar kunnen die side effects hebben? Zal haast wel, lastig om daar op te checken namelijk. Dan doet "obj.x = 1; obj.x = 1;" ineens iets anders dan "obj.x = 1;". Dat verwacht je niet, want je denk gewoon een geheugen var te zetten. Met de functie haakjes zie je in ieder geval dat er een functie wordt aangeroepen met mogelijke side effects. (ofwel "obj.x() = 1", of "obj.x(1);" wederom nog eens twee mogelijkheden om de dingen te doen)

Wat ik persoonlijk direct het grootste nadeel vind van properties: als je een functie aanroept weet je dat er side-effects kunnen zijn en dat 90% van de CPU-tijd van je applicatie erin kan zitten. Bij properties is dat onzichtbaar en verwacht je het niet altijd.

In feite zijn dat generics, templates worden meestal als iets brder begrip gezien. Maar je hebt wel gelijk natuurlijk als je dat onderscheid niet maakt.

Nee, daarin heb je absoluut geen gelijk Lees dit heldere artikel eens.

[PrisonerOfPain]

curry684 schreef op 28 juli 2004 @ 16:05:
Wat ik persoonlijk direct het grootste nadeel vind van properties: als je een functie aanroept weet je dat er side-effects kunnen zijn en dat 90% van de CPU-tijd van je applicatie erin kan zitten. Bij properties is dat onzichtbaar en verwacht je het niet altijd.

Dat je zoiets niet verwacht heeft grotendeels met de jezelf te maken en niet zozeer met het gebruik ervan. Zoiets krijg je wel door als je er een tijdje mee gewerkt hebt.

[Verwijderd]

Het hangt er maar net vanaf wat je bedoelt met "generics".

Bedoel je daarmee de brede klasse van Generic Programming technieken (zie voor Wikipedia link één van mijn vorige posts), of bedoel je daarmee generics zoals ze werken voor .NET?

Ik heb dat artikel trouwens doorgelezen... best interessant, maar het zat er natuurlijk aan te komen dat in zo'n dynamische omgeving generics moeilijk te realiseren zijn. Dat is ook de reden dat ze niet in de eerste release zaten.

En ik zie alweer een type-hell aankomen: een generiek type dat tussen assemblies gedeeld moet worden, moet uit een externe assembly komen. En aangezien er vast geen standaardassemblies zijn met standaardtypen zijn, gaat elke ontwikkelaar die een generic parameter in de public interface van zijn assemblies heeft staan, een assembly meeleveren met daarin de definitie van de generic parameter.

En als je dan assemblies van twee verschillende makers gaat gebruiken die allebei een List<int> verwachten, moet je uit allebei hun externe assemblies apart het List<int> type gaan halen, die weer niet compatible zijn, en ARGH, als ik er alleen al aan denk lopen de rillingen over m'n rug...


En om trouwens de vraag uit het topic te beantwoorden, "OOP, hoever ga je?". Nou, "best ver" [offtopic] .

[ Voor 13% gewijzigd door Verwijderd op 28-07-2004 16:20 ]

[Zoijar]

curry684 schreef op 28 juli 2004 @ 16:05:
dit heldere artikel eens.

Zal het zo eens lezen. Ik neem aan dat je gelijk hebt

[curry684]

PrisonerOfPain schreef op 28 juli 2004 @ 16:15:
[...]

Dat je zoiets niet verwacht heeft grotendeels met de jezelf te maken en niet zozeer met het gebruik ervan. Zoiets krijg je wel door als je er een tijdje mee gewerkt hebt.

Da's natuurlijk een kul-argument. Ik moet kunnen integreren met een 3rd party library zonder in de docs na te hoeven lezen dat de getter van property X een query met 5 full outer joins gaat doen met full-text search over een totaal van 3 miljoen records.

Een property impliceert een snelle operatie, en een functie kan lang duren. En helaas houden niet alle developers zich daaraan, wat een potentiele zwakte is van properties.

[ Voor 14% gewijzigd door curry684 op 28-07-2004 16:55 ]

[PrisonerOfPain]

curry684 schreef op 28 juli 2004 @ 16:54:
Da's natuurlijk een kul-argument. Ik moet kunnen integreren met een 3rd party library zonder in de docs na te hoeven lezen dat de getter van property X een query met 5 full outer joins gaat doen met full-text search over een totaal van 3 miljoen records.

Bij een method heb je toch precies hetzelfde probleem, maar omdat jij verwacht dat het snel gaat omdat het een property is. Daarbij kun je halverwegen een project niet ineens een property omgooien naar een method omdat 'ie langzaam blijkt.

Een property impliceert een snelle operatie, en een functie kan lang duren. En helaas houden niet alle developers zich daaraan, wat een potentiele zwakte is van properties.

Een property is een eigenschap van de class dat een bewerking snel of langzaam is heeft daar vrij weinig mee te maken.
Voorbeeld, een class om een window te tekenen kun je een kleur toekennen. Die kleur is in een database opgeslagen op een dusdanige manier dat het setten daarvan erg lang duurt. Moet je daarom maar een setColor() maken omdat je daarvan kan weten dat 'ie langzaam is, in plaats van een (IMHO) correctere Color property.

[Verwijderd]

Volledig mee eens, Prisoner. En trouwens, als je een setColor() ziet, verwacht je ook niet dat die lang gaat duren (het is immers toch maar een setter?).

Als je dat probleem in het echt tegen zou komen is het netter om een Color property te gebruiken, deze te cachen, en interactie met de database laten gaan via methodes als Retrieve en Store, als je dat liever hebt.

[Grijze Vos]

Om weer terug te komen op PHP.

Ikzelf gebruik 4 hoofdklassen op het moment:

core:
afhandelen van alle basisdingen, settings van modules regelen, de juiste variabelen uit het array trekken.

database:
spreekt met mn database, bevat enkele handige dingen om complete multi-dimensionele arrays zo middels een functie uit de db te trekken.

useraccess:
Welk userlevel heeft onze user, mag hij modereren, etc.

bbparser:
regelt de invoer naar de database toe, en de uitvoer van de database, om de bb mooi clean te houden en te formatten naar goede html. Hij kan tegenwoordig ook een javascript parser uitspuwen als de gebruiker die optie aanzet.

-----

De rest is bij gewoon plain code met functies, en geen OOP. Tot nu toe vind ik dit het fijnste scripten.

[ Voor 3% gewijzigd door Grijze Vos op 28-07-2004 18:05 ]

[MisterData]

Voor configs gebruik ik tegenwoordig constants in PHP5:

PHP:

<?php
class pnpConfig {
    
    /* database */
    const dbType = "MySQL";
    const dbHost = "localhost";
    const dbUser = "******";
    const dbPassword = "*************";
    const dbName = "***********";
    
    /* session */
    const sessionPrefix = "__pnp_";
    
    /* default template type */
    const defaultTemplateEngine = 'xslt';
};
?>

Verder voor sessies 1 class (pnpSession), voor de database is er een pnpDatabase-class en een pnpResult-class. Hiervan dient dan een class afgeleid te worden per dbms: zo krijg je pnpMySQLDatabase extends pnpDatabase en pnpMySQLResult extends pnpResult

[ Voor 33% gewijzigd door MisterData op 28-07-2004 19:39 ]