Scriptorama.nl

Reageer ook!

Zet scalar typehints maar ook op het verlanglijstje. :P

Door Daan op 02.22.07 @ 10:52 am | Permalink

"Stephan zou ook graag een 'object' typehint zien zodat hij kan aangeven dat een bepaalde functie of methode alleen een object kan ontvangen."

Het kan zijn dat ik het verkeerd begrijp, maar dit is gewoon mogelijk:

Door Jip op 02.22.07 @ 1:06 pm | Permalink

Mja je zou bijvoorbeeld een interface kunnen maken en die de naam `Object` kunnen geven, maar dat is ook niet ideaal.

Ik ga idd ook voor de typehints, maar dan wordt php weer een beetje een sterkgetypeerde taal en dat was volgens mij toch niet helemaal de bedoeling dat ik een keer gelezen heb @ comments van php medewerkers.

Door Iwan luyks op 02.22.07 @ 2:13 pm | Permalink

- namespaces
- migrate.php.net: migratie-handleiding voor hosters en gebruikers

En in de categorie 'pipe dream':
- lambda functions zonder eval()/create_function() ongein
- named function parameters
- operator methods
- array shorthand: [foo: 'bar', bar: foo], [1, 2, 3]
- arrays als objecten
- throw shorthand voor single catch statement: throw 'foo' wordt automagisch throw new Exception('foo')

Door Michel de Lange op 02.22.07 @ 4:38 pm | Permalink

@Iwan:

> dan wordt php weer een beetje een
> sterkgetypeerde taal en dat was volgens mij
> toch niet helemaal de bedoeling dat ik een keer > gelezen heb @ comments van php medewerkers.

De mogelijkheid tot typehinting is natuurlijk geen verplichting tot het gebruik ervan.. Dus ik zie geen belemmeringen..

Door Berry__ op 02.22.07 @ 4:42 pm | Permalink

Ik ga ook voor het migratie stuk. Dat is het grootste probleem met php5.

Door Ivo Jansch op 02.22.07 @ 9:52 pm | Permalink

Mogelijkheid om te verwijzen naar DE child vanuit de parent:

Ik krijg dit maar niet voor elkaar.

Door Koen Speelmeijer op 02.25.07 @ 10:52 pm | Permalink

Stephan Schmidt heeft er inmidddels nog 1 gepost:

http://www.stubbles.org/archives/8-My-wishlist-for-PHP-6,-pt3-Annotations.html

Door Mathieu Kooiman op 02.26.07 @ 8:25 am | Permalink

@Koen: in wat voor context zou je dat willen gebruiken dan? Klinkt eerder als iets waar een design verbeterd kan worden :)

Door Mathieu Kooiman op 02.26.07 @ 8:26 am | Permalink

Ik poste een voorbeeld code maar die werd blijkbaar genegeerd. Nog ens proberen:

-----
class ParentClass {
public static function calledViaChild() {
return child::$_protectedVar;
}
}
class ChildClass1 extends ParentClass {
public static $_protectedVar = "foo";
}
class ChildClass2 extends ParentClass {
public static $_protectedVar = "bar";
}

echo ChildClass1::calledViaChild(); // foo
echo ChildClass2::calledViaChild(); // bar
------------
Zoiets is momenteel nog niet mogelijk voor zover ik weet.

Door Koen Speelmeijer op 02.26.07 @ 5:42 pm | Permalink

Lees de handlijding is man :)
Kan dus wel!

Als je een class overneemd dan worden die parent functies onderdeel van het child.

Dus als je op de child een functie uitvoerd van die komt van de parent dan ziet die functie gewoon de parent en child als een.
Alleen is het zo dat als de child een var of functie heeft die het zelfde heet als die van de parrent dan word die van de parent overschrijven maar kan je nog wel met parent:: aanroepen.

Of zo iets, in het donken typen met een zwarttoetsennboord naar niet samen :)

Door Sebastiaan Stok op 02.28.07 @ 8:12 pm | Permalink

Koen bedoelt juist iets anders. Hij wil wanneer hij een overervende klasse heeft gemaakt vanuit de Parent een nieuwe waarde van de Child uitlezen. Een soort bi-directionele inheritance.

Dat gaat uiteraard niet gebeuren. Het idee is juist dat een overerfende klasse de parent uitbreidt. En niet dat de parent op wijzigingen in de childs bouwt.

Ik vraag me dan ook af in wat voor situatie je dit uberhaupt zou willen gebruiken :)

Door Mathieu Kooiman op 03.01.07 @ 8:05 am | Permalink

Een voorbeeldje, bij een Model klasse die geen databasekolom maar een databasetabel voorstelt:

Ik maak hier gebruik van de fictieve constante 'child'.
(even aannemen dat self::$_db is geset in een soort van 'init' methode)
----
class DP_Model {
public static function add($data) {
self::_filter($data); self::$_db->insert(child::$_table, $data);
}

public static function update($data, $where, $quoteInto = array()) {
self::_filter($data);
self::$_db->updata(child::$_table, $data, $where, $quoteInto);
}

public static function delete($id) {
self::_filter($data);
if(child::$_hasDeleteColumn) {
self::$_db->update(child::$_table, array('deleted' => 1), 'id = ?', $id);
} else {
self::$_db->delete(child::$_table, $id);
}

public static function recover($id) {
if(child::$_hasDeletedColumn) {
self::$_db->update(child::$_table, array('deleted' => 0), 'id = ?', $id);
} else {
// error throwen of iets dergelijks
}

protected static function _filter(&$data) {
$data = array_intersect_key($data, array_flip(child::$_columns);
}
}
-----

En dan zal je heel toffe klassen hiervan kunnen extenden:

-----
class User extends DP_Model {
protected $_table= "user";
protected $_hasDeletedColumn = true;
protected $_columns = array('username', 'first_name', 'last_name', 'email', ...);
}

class ForumPost extends DP_Model {
protected $_table = "forum_posts";
protected $_hasDeletedColumn = true;
protected $_columns = array('owner', 'body_id', 'created');
}
-------

==>

-----
User::add(array('username' => 'a username', 'first_name' => 'Koen', 'last_name' => 'Speelmeijer', 'email' => '...', 'aNonExistantColumn' => 'value');
// die laatste wordt dan genegeerd
ForumPost::delete(5);
// enz enz enz
-----

Nu moet ik het zo doen:
----
User::instance()->add(....);
----

Is er trouwens een ubb code voor codes, omdat het er nu niet uitziet.
Hier heb ik ook even de code gepost voor de uitleining:
http://v2.pastebin.be/188

Door Koen Speelmeijer op 03.01.07 @ 3:55 pm | Permalink

"Dat gaat uiteraard niet gebeuren. Het idee is juist dat een overerfende klasse de parent uitbreidt. En niet dat de parent op wijzigingen in de childs bouwt."

Hier ben ik het trouwens niet mee eens omdat bij 'niet-statisch' klassen dit wel zo gebeurd. Dit is volgens mij hetgene waar polymorfisme op gebasseerd is als ik me niet vergis. Dat de parent aan child members kan.

Door Koen Speelmeijer op 03.01.07 @ 3:58 pm | Permalink

Het idee van polymorfisme is dat je de Childs kunt aanspreken alsof ze hun Parent waren. De parent is nml de lowest common denominator.

Om even verder op jouw idee te bouwen:

PLAIN TEXT

PHP:

1. class ModelProcessor
2. {
3.   function Process(DP_Model $model)
4.   {
5.     $model->delete(5);
6.   }
7. }

Op de manier kun je alle instanties en childs van DP_Model aan ModelProcess::Process() voeren. Alle childs van DP_Model hebben immers de methodes die DP_Model aanbiedt.

Ik ben sowieso niet zo'n fan van statische methodes zoals jij ze gebruikt aangezien je op deze manier een stuk flexibiliteit inlevert. Want, wanneer je User::add() gebruikt, is je code hard gebonden aan de user klasse en dat is niet altijd gewenst.

Door Mathieu Kooiman op 03.02.07 @ 7:41 am | Permalink

Je kunt overigens [ php ] [ /php ] gebruiken voor PHP code.

Door Mathieu Kooiman op 03.02.07 @ 7:41 am | Permalink

Het idee achter overerving is nu juist dat je subklassen kunt toevoegen zonder dat de parentklasse daar iets van af weet. Dit heeft te maken met herbruikbaarheid, een belangrijk punt uit de OOP. Als je kennis over children in de parent zou opnemen, moet je voor iedere wijziging in de childklasse ook de parent aanpassen (tenminste als de interface wijzigt). Het idee is juist dat dat niet moet.

Polymorfisme is inderdaad het concept dat je een subklasse kunt benaderen alsof het een klasse van het type van de (een) parent is.

Voorbeeld:

interface Writeable {
public function save();
public function load();
}

class Parent {
...
public function doeJeDing() {
}
...
}

class Child extends Parent implements Writeable {
...
}

// main code
$oDing = new Child();
// dit mag nu
doeIetsMetWriteables($oDing);
// maar dit ook
doeIetsMetParent($oDing);

// functies die polymoprfisme gebruiken
function doeIetsMetWriteables(Writeable $p_oObject) {
$p_oObject->save();
}

function doeIetsMetParent(Parent $p_oObject) {
// doe iets
}

Door Wouter Tengeler op 11.08.07 @ 11:59 am | Permalink

Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Name (required)

Mail (will not be published) (required)

Website

Volg Scriptorama via RSS!