note 20246 added to language.oop

There is a great solution for "plugin" API developer's wich didn't know how a extended class would be called later, but likes to use ones. It's a little tricky way of using a interface_class and the variable variables. I just like to throw you into water and let you learn from following example: [example] class my_interface{ function foo($msg){ /*it does nothing, and it could be totally ignored.. but it is a help for the class definitions. Just to prevent that things get messed up when "plugin" developers play the "try/error" game... */ } } class foobar extends my_interface{ function foo($msg){ echo "foobar:: $msg"; } } class hello_world extends my_interface{ function foo($msg){ echo "we say hello and '$msg' to the whole world"; } } // now the interesting part :) $used_interface = "foobar"; $obj = new $used_interface (); $obj->foo("hallo"); [/example] Now... try to set up other my_interface childs... the interesting thing ist the variable "$used_interface"! You must insert a valid class name into this variable, otherwise you get an "cant instanctiate class... " error. So, now, you can create a class only by knowing it's name - without hardcoding! Why the hell using an interface class? Well... see it as an help... for you and for the plugin developers. The plugin dev's will know what the api want's, and you know what your api could process... ;) It works fine under php 4.0.6. Greetz s.hagenbrock Btw... don't forget to include the class files. Else you get an "undefined class" error ;) -- http://www.php.net/manual/en/language.oop.php http://master.php.net/manage/user-notes.php?action=edit+20246 http://master.php.net/manage/user-notes.php?action=delete+20246 http://master.php.net/manage/user-notes.php?action=reject+20246