before beta 2

Hello Jon, Monday, June 30, 2003, 9:58:07 AM, you wrote: JP> Everything is working well for me now, and I'd prefer to keep it that JP> way. If you did had a closer look then you'd've find out that essential things are not working. Did you try the new oo stuff? JP> I'm wary of adding new features (I consider integrating SPL to JP> be a new feature, for instance) which may upset the stability that JP> we've just recently achieved. SPL is older than SQLite for instance and as i said tested very well. What we are speaking about here is to move certain features into the engine to be more efficient. Best regards, Marcus mailto:helly@php.net

I refer you to the jargon file, which is about as good a definition that you can get: http://info.astrian.net/jargon/terms/b/beta.html "Mostly working, but still under test; usu. used with `in': `in beta'. In the Real World, systems (hardware or software) software often go through two stages of release testing: Alpha (in-house) and Beta (out-house?). Beta releases are generally made to a group of lucky (or unlucky) trusted customers. 2. Anything that is new and experimental. "His girlfriend is in beta" means that he is still testing for compatibility and reserving judgment. 3. Flaky; dubious; suspect (since beta software is notoriously buggy)." This is the definition of a beta. Now, PHP 5 Beta 1 certainly falls well within these parameters. How far you subclassify depends on the project. MySQL betas are often recommended in production environments. PHP Betas are a bit looser about new features and signifigant changes. We aren't violating the definition of a beta, we are just defining our parameters for beta software. "Alpha," "Beta" and "Release" are classifications, and are left to the project to further define. PHP 5 is almost there, and prematurely imposing rules on ourselves because we now labeled a "beta" seems like an unwise choice. The majority of the changes marcus is talking about are not far reaching, and are really about polishing off the object model. Perfectly acceptable discussion for a beta cycle. -Sterling On Sun, 2003-06-29 at 23:54, Dan Kalowsky wrote:

At 08:20 30/06/2003, Sterling Hughes wrote:

I agree with every word... Zeev

Hello Andi, Tuesday, July 1, 2003, 7:33:45 AM, you wrote: AG> Hi, AG> It is still not possible to understand from this .diff what the impact on AG> the Engine will be No? There a simply 4 additional checks/calls inside zend_execute.c. You can't see the impact of them? strange! But see down below. AG> because the code it still saturated with copying of code AG> from the Engine. No! The code works quite a bit different. If something should be changed then the code inside the engine should be changed - but again it's different. And all we are speeking about here is a) code inside spl_functions.c/h which is also needed for the spl extension. b) spl_call_method() which works quite different from fast_call_user_function() -> the spl code assumes a loop and: - only works with methods (no function support) - expects the class type (zend_class_entry) to be known prior to calling - stores the fetched function if not already known c) some additional static inlines around spl_call_method() d) however with the following you might be correct: - spl_is_instance_of() - spl_unlock_zval_ptr_ptr() - spl_get_zval_ptr_ptr() but that would make it necessary to move some macros and inlines of the engine around. So i supposed that would be a good thing to do in step 2. AG> My intentation was to review a patch that is ready to be AG> commited. You shouldn't have to replace opcodes anymore I don't replace any opcode.... AG> and you shouldn't AG> have to make copies of functions from within Zend. Read above... AG> Also, does the array overloading stuff allow extension developers like AG> Andrei also to hook into this? ATM i act like if hooking weren't possible and emit an error if a wrong object is used. Since spl was an extension before and showed that this is no problem because the hooks get executed before the original handlers and becuse we need errors if noone handles the objects - i guess that's the way to go. Or in quick yes he can do what ever he wants to do. Only by using spl code it's easier for him and it will be compatible with other things if he uses the same interfaces. Just for clearification here is the part of the diff that causes impact on the runtime behaviour (i've removed the includes and WS): Index: Zend/zend_execute.c =================================================================== RCS file: /repository/ZendEngine2/zend_execute.c,v retrieving revision 1.481 diff -u -p -r1.481 zend_execute.c --- Zend/zend_execute.c 30 Jun 2003 20:22:35 -0000 1.481 +++ Zend/zend_execute.c 1 Jul 2003 00:16:33 -0000 @@ -3099,6 +3101,11 @@ int zend_case_handler(ZEND_OPCODE_HANDLE int zend_switch_free_handler(ZEND_OPCODE_HANDLER_ARGS) { + zval **obj = get_zval_ptr_ptr(&EX(opline)->op2, EX(Ts), BP_VAR_R); + + if (obj) { + spl_switch_free_handler(obj , ZEND_OPCODE_HANDLER_ARGS_PASSTHRU); + } zend_switch_free(EX(opline), EX(Ts) TSRMLS_CC); NEXT_OPCODE(); } # # This is one additional fetch and check at the end of each foreach loop. # @@ -3515,18 +3522,30 @@ int zend_fe_reset_handler(ZEND_OPCODE_HA { zval *array_ptr, **array_ptr_ptr; HashTable *fe_ht; + zend_class_entry *instance_ce; if (EX(opline)->extended_value) { array_ptr_ptr = get_zval_ptr_ptr(&EX(opline)->op1, EX(Ts), BP_VAR_R); if (array_ptr_ptr == NULL) { MAKE_STD_ZVAL(array_ptr); } else { - SEPARATE_ZVAL_IF_NOT_REF(array_ptr_ptr); - array_ptr = *array_ptr_ptr; - array_ptr->refcount++; + if ((instance_ce = spl_get_class_entry(*array_ptr_ptr TSRMLS_CC)) != NULL) { + if (!spl_fe_reset_handler(array_ptr_ptr, instance_ce, ZEND_OPCODE_HANDLER_ARGS_PASSTHRU)) { + return 0; + } + } else { + SEPARATE_ZVAL_IF_NOT_REF(array_ptr_ptr); + array_ptr = *array_ptr_ptr; + array_ptr->refcount++; + } } } else { array_ptr = get_zval_ptr(&EX(opline)->op1, EX(Ts), &EG(free_op1), BP_VAR_R); + if ((instance_ce = spl_get_class_entry(array_ptr TSRMLS_CC)) != NULL) { + if (!spl_fe_reset_handler(&array_ptr, instance_ce, ZEND_OPCODE_HANDLER_ARGS_PASSTHRU)) { + return 0; + } + } if (EG(free_op1)) { /* IS_TMP_VAR */ zval *tmp; # # One additional zend_class_entry fetch per foreach loop begin. # In both cases the fetch is done by a static inline function which does two # simple comparisons and one complex (if you want i can eliminate on of the # simple checks, but i wouldn't like it). # @@ -3560,6 +3580,10 @@ int zend_fe_fetch_handler(ZEND_OPCODE_HA char *str_key; ulong int_key; HashTable *fe_ht; + + if (Z_TYPE_P(array) == IS_STRING) { + return spl_fe_fetch_handler(&array, ZEND_OPCODE_HANDLER_ARGS_PASSTHRU); + } PZVAL_LOCK(array); # # This is one additional integer comparison and one assembler jump per foreach # loop iteration. Hey that is definitley near zero impact. # Best regards, Marcus mailto:helly@php.net

--- Andi Gutmans <andi@zend.com> wrote:

I think a callback like __array($index) { } for all objects would be a nice feature, so Andrei for gtk and spl wouldn't have to overload the opcode for each application of this. I think it could become a pretty popular feature when developers see that it can be done. - Brad __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com