LB>> The way python handle this is just fine and allow much more code magic LB>> in classes.
I don't think "more magic" is neccessarily good thing. LB>> The python rule : if we have a __get, __set, __call, we use it. no LB>> more no less. This will: a) slow down *a lot* any class that has accessors b) put all the variable handling on the user (you will have to check *each* access to the class property, with no opt-out). c) make impossible or unclear to work with classes that both have defined variables and have accessors - either we get loops or we get some hard-to-catch magic - you will never know if the access to variable will call accessor or not. LB>> and to be sure this design will be usuable, php would produce 3 LB>> functions with references everywhere: LB>> LB>> object_set($object, $varName, $value) LB>> object_get($object, $varName) LB>> object_call($object, $method, $arguments[]) LB>> LB>> tada ! python way of coding : clean, simple, powerfull within your LB>> favorite web scripting language. I don't know Python ways, but from your explanation is looks to me neither simple, nor clean. As for power, Assembler is powerful too :) That's strictly IMHO, of course. LB>> Of course this thing is possible with the current system but it requires LB>> the following : LB>> LB>> 1 - do not declare 'var $bar' or declare it private (need some more test LB>> for private but not the right solution as the magic requires public LB>> access). Right, accessors are called for undefined properties. LB>> 2 - create a private hashtable which will handle undeclared variables LB>> (because once a variable is set in the object's properties array, __get LB>> and __set won't work anymore with it) Right. That's why you use accessors, not - you don't want variables to be manipulated directly. LB>> 3 - create the __get() method so we can retrieve the variable from the LB>> private hashtable. That you will have to do in any case. LB>> 4 - disable error_reporting(E_ALL) because $object->myvar is not LB>> declared and you can't ask it in your code. That has nothing to do with it - accessor should take care for this, it won't both call accessor and issue warning. LB>> Well, all this will make the code uggly, unclear to document, hard to LB>> maintain, and will take anybody about 3 times the same to develop the LB>> above example... And of course you're limited as you can't call other LB>> variables setters while in __set (same for __get and __call)! I don't see how this would make the code ugly. And I don't see how you could allow to recursively call accessors in your model (BTW, current model could allow recursion in some cases - your should have recursion always prohibited, unless you prevent /by internal PHP means/ accessors from touching variables inside the object at all). LB>> To finish with, i hope you'll teach me advantages of the current LB>> design because i took a look at the zend_object_handlers.c and ... LB>> well ... i really think there's a 5:00 am conception mistake behind LB>> the scene :) I don't think so. Now if you explain what's the problem with it (except for "Python does it other way", which is fine by me but I'm not a Python fan so it says nothing to me but a bit of trivia) I could answer it point by point. LB>> - when will "use()" be implemented (a package attempt i bet) ? What is "use()"? LB>> - get_class_methods() do not return methods array when used on a LB>> namespaced class Submit a bug report with code example. You may also want to copy the report (with code example, if I didn't mention this yet) to the list. This is not only for this, but also for any other things you think are bugs. Code example does great things to syncronize about what is the problem. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
