Re: [PHP-DEV] [RFC] prototyping
On 1/14/2009 01:15, Stanislav Malyshev wrote:
Hi!
Also, this adds very new thing to PHP - objects that change while
being assigned. I am not sure it is a good thing.
Well Closures are a brand new thing in PHP. So far we had nothing even
remotely close to the closures we have right now.
There are a lot of different features in PHP, that's not the reason to
turn the engine into a salad of special cases and exceptions. That's why
making Closure an object and having __invoke was a good idea - because
it fits what the engine already does very well. Having special case just
for one class doesn't fit it so well.
you wrote. And in my opinion it also makes the most sense. A closure
keeps
its state.
I consider $this be a part of this state. Maybe if you really need it
it'd be fine to do something like $closure-setThis($object)...
Why would you call __get() here? Becasue I did that by mistake in my very
Imagine such code:
class Contains {
private $_store;
function __set($n, $v) {
$this-_store[$n] = $v;
}
function __get($n) {
return $this-_store[$n];
}
}
Pretty standard class. Now imagine you do this:
$c = new Contains();
$c-foo = bar;
echo $c-foo;
works well and basically you see Contains as regular object and couldn't
care less it has handlers and not properties. Now this:
$c-bar = function() { }
$c-bar();
what happens here? You can't get the value of bar without calling
__get and if you call __call instead that means you either lost $c-bar
or you have two kinds of properties now - ones that call __get and ones
that don't. I don't see how it is good.
That is one example of convoluted code that is already possible. If a
developer creates such a mess is his fault.
As Marcus said, it is already possible to call properties. All we have
to do is implement __call(). Not being forced to implement __call in
cases where we want object augmentation with lambdas is just syntactic
sugar. I agree though that a rebind()/setThis() method on the Closure
object is needed, but $this should be rebound by default.
Auto-magically binding $this to the current object, whatever that may
be, is a missing feature that requires a developer to pass the instance
as an argument to that lambda.
class A
{
protected $_lambdas = array();
public function __set($name, $lambda)
{
$this-_lambdas[$name] = $lambda;
}
public function __call($lambda, $args)
{
$args = array_merge($this, $args);
return call_user_func_array($this-_lambdas[$lambda], $args);
}
}
$a = new A;
$a-foo = function($this) {
var_dump($this);
};
$a-foo();
Now, the above code is already possible, but... by implementing callable
properties a developer is spared the effort of implementing a __call()
method. The only problem now is that by deciding to not implement
__call() he loses a nice opportunity of passing the instance object and
he's left with some ugly alternatives:
class B
{}
$b = new B;
$b-foo = function($this) {
var_dump($this);
};
$b-foo($b);
// how would be the above call different than?
$foo = function($object) {
var_dump($object);
}
$foo($b);
// Or would you believe this is just fine?
$b-foo = function() use ($b) {
var_dump($b);
};
$b-foo();
Sooner or later, people would want that use statement to be dismissed
for an auto-magically bound $this. It's also the problem of accessing
protected and private members.
JavaScript does automatic binding of the this instance which is
actually a key point in prototyping. Well, strictly speaking this is not
prototyping, is augmentation. Adding members to the JS prototype object
means that *any* existing and further instances will share those
members. Augmentation is just about adding members to an existing
instance. Real prototyping is though possible in PHP 5.3:
class A
{
/**
* Lambdas available to all instances
*/
public static $lambda;
public function __call($method, $args)
{
$method = self::$lambda;
return call_user_func_array($method, $args);
}
}
A::$lambda = function() {
return 'foo';
};
$a1 = new A;
$a2 = new A;
echo $a1-lambda();
echo $a2-lambda();
The problem of binding $this appears again, but I believe this use case
is much harder to solve because there's no $this in the moment we add
lambdas to the class. Anyway, it's a point to consider.
No, becasue Closure cannot be derived as it is a final class. If we
change
Why it's a final class? Any special reason for that?
It matters how you bind static variables to it as they are taken from the
context. And by the binding you keep the context. Sure all right. But we
bind this in a completely different way.
I see no reason to have two contexts in closure - one bound one way and
another bound another way. I think context is a context - it's where the
closure was created.
different from an assignment outside the class? And it gets even
better, if
you assign that closure to another
[PHP-DEV] Compatibility of PHP 5.3 and PHP 6.0 against Windows 7
Hey Folks! Since I am a tester of Windows 7, I took the time to run several thousand test to prove the compatibility. Apart from amazingly less required changes at the side of the user, it ran fluently. I'm looking forward to continue the testing at this platform. Thanks, -- (c) Kenan Sulayman Freelance Designer and Programmer Life's Live Poetry http://kkooporation.de/
Re: [PHP-DEV] Compatibility of PHP 5.3 and PHP 6.0 against Windows 7
On Wed, Jan 14, 2009 at 5:32 PM, Kenan R Sulayman kur...@kkooporation.de wrote: Hey Folks! Since I am a tester of Windows 7, I took the time to run several thousand test to prove the compatibility. Apart from amazingly less required changes at the side of the user, it ran fluently. I'm looking forward to continue the testing at this platform. 5.3 should work smoothly, even the newest features. A couple of vista/2k8/w7 only features should be available too soonish (like links). Thanks for testing! By the way, we have a windows internals list, see the list page on www.php.net :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Bug 47002 - Fields truncated
Greetings PHP people,
I have written a patch to resolve the issue mentioned in the subject. Also I
wrote a small test case for it. This patch is to be applied on PHP5_2 CVS.
Still in this matter, I have written a patch for dbase.c (this was based on
Felipe's patch which seems to have been lost) to use zend_parse_parameters
and also to check for the PHP version to define if the arginfo should
receive a static identifier or not.
The patches are attached, and so is the test case.
These files can also be found in the following URLs:
Patch for the bug: http://felipe.ath.cx/typoon/dbase_php5.2.9_bug47002.diff
Patch for dbase.c: http://felipe.ath.cx/typoon/dbase_php5.2.9.diff
Test case for the bug: http://felipe.ath.cx/typoon/bug47002.phpt
Currently I am also working on getting the dbase fixed in the PECL
repositories so we can have a release (just finishing writing some test
cases).
In case there are any doubts or problems, please let me know so I can
verify.
BTW, I am Gilgamesh on #php.pecl (sometimes shows up as typoon because of
problems with mibbit). So you can also contact me there :)
Thanks!
Henrique
Index: ext/dbase/dbase.c
===
RCS file: /repository/php-src/ext/dbase/Attic/dbase.c,v
retrieving revision 1.74.2.2.2.11
diff -u -u -w -b -r1.74.2.2.2.11 dbase.c
--- ext/dbase/dbase.c 31 Dec 2008 11:17:36 - 1.74.2.2.2.11
+++ ext/dbase/dbase.c 14 Jan 2009 16:49:21 -
@@ -57,6 +57,12 @@
#define DBase_TLS_VARS
#endif
+#if (PHP_MAJOR_VERSION == 5) (PHP_MINOR_VERSION = 3) || PHP_MAJOR_VERSION
5
+#define STATIC_ARGINFO
+#else
+#define STATIC_ARGINFO static
+#endif
+
#include fcntl.h
#include errno.h
@@ -118,41 +124,42 @@
Opens a dBase-format database file */
PHP_FUNCTION(dbase_open)
{
- zval **dbf_name, **options;
+ char *dbf_name;
+ int dbf_name_len;
+ long options;
+
dbhead_t *dbh;
int handle;
DBase_TLS_VARS;
- if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, dbf_name,
options) == FAILURE) {
- WRONG_PARAM_COUNT;
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, sl, dbf_name,
dbf_name_len, options) == FAILURE) {
+ return;
}
- convert_to_string_ex(dbf_name);
- convert_to_long_ex(options);
- if (!Z_STRLEN_PP(dbf_name)) {
+ if (!strlen(dbf_name)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, The filename
cannot be empty.);
RETURN_FALSE;
}
- if (Z_LVAL_PP(options) == 1) {
- php_error_docref(NULL TSRMLS_CC, E_WARNING, Cannot open %s in
write-only mode, Z_STRVAL_PP(dbf_name));
+ if (options == 1) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, Cannot open %s in
write-only mode, dbf_name);
RETURN_FALSE;
- } else if (Z_LVAL_PP(options) 0 || Z_LVAL_PP(options) 3) {
- php_error_docref(NULL TSRMLS_CC, E_WARNING, Invalid access
mode %ld, Z_LVAL_PP(options));
+ } else if (options 0 || options 3) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, Invalid access
mode %ld, options);
RETURN_FALSE;
}
- if (PG(safe_mode) (!php_checkuid(Z_STRVAL_PP(dbf_name), NULL,
CHECKUID_CHECK_FILE_AND_DIR))) {
+ if (PG(safe_mode) (!php_checkuid(dbf_name, NULL,
CHECKUID_CHECK_FILE_AND_DIR))) {
RETURN_FALSE;
}
- if (php_check_open_basedir(Z_STRVAL_PP(dbf_name) TSRMLS_CC)) {
+ if (php_check_open_basedir(dbf_name TSRMLS_CC)) {
RETURN_FALSE;
}
- dbh = dbf_open(Z_STRVAL_PP(dbf_name), Z_LVAL_PP(options) TSRMLS_CC);
+ dbh = dbf_open(dbf_name, options TSRMLS_CC);
if (dbh == NULL) {
- php_error_docref(NULL TSRMLS_CC, E_WARNING, unable to open
database %s, Z_STRVAL_PP(dbf_name));
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, unable to open
database %s, dbf_name);
RETURN_FALSE;
}
@@ -165,22 +172,22 @@
Closes an open dBase-format database file */
PHP_FUNCTION(dbase_close)
{
- zval **dbh_id;
+ long dbh_id;
dbhead_t *dbh;
int dbh_type;
DBase_TLS_VARS;
- if (ZEND_NUM_ARGS() != 1 || (zend_get_parameters_ex(1, dbh_id) ==
FAILURE)) {
- WRONG_PARAM_COUNT;
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, l, dbh_id) ==
FAILURE) {
+ return;
}
- convert_to_long_ex(dbh_id);
- dbh = zend_list_find(Z_LVAL_PP(dbh_id), dbh_type);
+
+ dbh = zend_list_find(dbh_id, dbh_type);
if (!dbh || dbh_type != DBase_GLOBAL(le_dbhead)) {
- php_error_docref(NULL TSRMLS_CC, E_WARNING, Unable to find
database for identifier %ld, Z_LVAL_PP(dbh_id));
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, Unable to find
database for identifier %ld, dbh_id);
[PHP-DEV] Re: [PATCH] Bug 47002 - Fields truncated
Oh, I missed one thing. I also had to fix test 001.phpt Attached is the patch for it, which can also be found in the following url: http://felipe.ath.cx/typoon/001.phpt.diff.txt Sorry for the confusion :$ Thanks! Henrique On Wed, Jan 14, 2009 at 11:16 AM, Henrique M. Decaria typ...@gmail.comwrote: Greetings PHP people, I have written a patch to resolve the issue mentioned in the subject. Also I wrote a small test case for it. This patch is to be applied on PHP5_2 CVS. Still in this matter, I have written a patch for dbase.c (this was based on Felipe's patch which seems to have been lost) to use zend_parse_parameters and also to check for the PHP version to define if the arginfo should receive a static identifier or not. The patches are attached, and so is the test case. These files can also be found in the following URLs: Patch for the bug: http://felipe.ath.cx/typoon/dbase_php5.2.9_bug47002.diff Patch for dbase.c: http://felipe.ath.cx/typoon/dbase_php5.2.9.diff Test case for the bug: http://felipe.ath.cx/typoon/bug47002.phpt Currently I am also working on getting the dbase fixed in the PECL repositories so we can have a release (just finishing writing some test cases). In case there are any doubts or problems, please let me know so I can verify. BTW, I am Gilgamesh on #php.pecl (sometimes shows up as typoon because of problems with mibbit). So you can also contact me there :) Thanks! Henrique Index: ext/dbase/tests/001.phpt === RCS file: /repository/php-src/ext/dbase/tests/Attic/001.phpt,v retrieving revision 1.1.2.2 diff -u -u -w -b -r1.1.2.2 001.phpt --- ext/dbase/tests/001.phpt25 Feb 2007 23:17:12 - 1.1.2.2 +++ ext/dbase/tests/001.phpt14 Jan 2009 17:34:28 - @@ -55,9 +55,9 @@ Warning: dbase_create(): Unable to create database without fields in %s on line %d bool(false) -Warning: dbase_create(): Expected array as second parameter in %s on line %d -bool(false) +Warning: dbase_create() expects parameter 2 to be array, integer given in %s on line %d +NULL -Warning: dbase_create(): Expected array as second parameter in %s on line %d -bool(false) +Warning: dbase_create() expects parameter 2 to be array, string given in %s on line %d +NULL Done -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prototyping
Hi, On 1/14/2009 18:29, Stanislav Malyshev wrote: Hi! That is one example of convoluted code that is already possible. If a developer creates such a mess is his fault. Convoluted? Mess? Are you kidding me? It's standard usage of access handlers. I don't understand how that could be standard when the example was about calling overloaded properties, which isn't yet possible in the language, as you vigilantly observed. Now, regardless whether is convoluted or not, you must agree that is better having callable properties in the language and documenting that this won't apply for overloaded properties. In the end you don't really need callable overloaded properties as a developer already has access to the internals of a class, thus __call() is all he needs to implement them (there would be at least a magic call anyway). It's a trade off but a worthy one in my opinion. Just as right now it is being documented that in order to call a lambda assigned to an instance property you need a temporary variable, it could be easily documented that one should not expect callable overloaded properties and must instead implement __call beside the standard __get/__set. It's a WTF but a smaller one this time. Anyway, there may be stronger arguments against so I'm interested in your opinion. Thanks, I. Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prototyping
Hi! Now, regardless whether is convoluted or not, you must agree that is better having callable properties in the language and documenting that this won't apply for overloaded properties. In the end you don't really I do not see any aspect in which it would be better. need callable overloaded properties as a developer already has access to Having features in the language that do not work together is usually a bad idea. Developer using overloads would expect it to work in most cases where properties work, and if this prototyping design can not do it I think it is a sign more work is needed to solve it before we can add it. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] build IDs proposal
Hi! As many of you know, one can build PHP engine in a number of ways which are binary-incompatible - debug/no debug, thread-safe/not thread safe, etc. Also, for windows we have now anther dimension - we could build with VC6, VC8, VC9, etc. Loading modules built with another, binary incompatible version, could lead to crashes and malfunctions, thus Zend extension and PHP extension loaders check these options, stored in special structure, to match module ones with engine ones. Now the problem is that when we need to add dimensions, we will have to change structures and maybe even edit some extensions, and as we have more dimensions it becomes less manageable and more hackish. I think that it would be better if we adopted more clean and scalable solution for that. I propose having one string build ID, which would look something like: API20071006,NTS,Debug,VC8 and would be rquired to match exactly in the engine and the module. This should be relatively easy to generate when compiling. Pro: 1. Easy, robust and scalable way to match current and any future build flavors 2. You can easily create private build flavors when testing binary-incompatible changes 3. Build data is in readable form even inside binary, so binaries could be automatically checked by Unix tools. Contra: 1. Well, it's change :) What do you think? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] build IDs proposal
On Wed, Jan 14, 2009 at 11:22 PM, Stanislav Malyshev s...@zend.com wrote: Hi! As many of you know, one can build PHP engine in a number of ways which are binary-incompatible - debug/no debug, thread-safe/not thread safe, etc. Also, for windows we have now anther dimension - we could build with VC6, VC8, VC9, etc. Loading modules built with another, binary incompatible version, could lead to crashes and malfunctions, thus Zend extension and PHP extension loaders check these options, stored in special structure, to match module ones with engine ones. Now the problem is that when we need to add dimensions, we will have to change structures and maybe even edit some extensions, and as we have more dimensions it becomes less manageable and more hackish. I think that it would be better if we adopted more clean and scalable solution for that. I propose having one string build ID, which would look something like: API20071006,NTS,Debug,VC8 and would be rquired to match exactly in the engine and the module. This should be relatively easy to generate when compiling. Pro: 1. Easy, robust and scalable way to match current and any future build flavors 2. You can easily create private build flavors when testing binary-incompatible changes 3. Build data is in readable form even inside binary, so binaries could be automatically checked by Unix tools. Contra: 1. Well, it's change :) What do you think? As said this morning during our little chat about that, I'm all for it, the sooner (now) the better. Another cons: - if we don't do that, I'll have to add a new element the struct to indentify which compiler/crt was used to build an ext. That was the reasons why this proposal comes in now :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] build IDs proposal
On 14.01.2009, at 23:22, Stanislav Malyshev wrote: Hi! As many of you know, one can build PHP engine in a number of ways which are binary-incompatible - debug/no debug, thread-safe/not thread safe, etc. Also, for windows we have now anther dimension - we could build with VC6, VC8, VC9, etc. Loading modules built with another, binary incompatible version, could lead to crashes and malfunctions, thus Zend extension and PHP extension loaders check these options, stored in special structure, to match module ones with engine ones. Now the problem is that when we need to add dimensions, we will have to change structures and maybe even edit some extensions, and as we have more dimensions it becomes less manageable and more hackish. I think that it would be better if we adopted more clean and scalable solution for that. I propose having one string build ID, which would look something like: API20071006,NTS,Debug,VC8 and would be rquired to match exactly in the engine and the module. This should be relatively easy to generate when compiling. Pro: 1. Easy, robust and scalable way to match current and any future build flavors 2. You can easily create private build flavors when testing binary- incompatible changes 3. Build data is in readable form even inside binary, so binaries could be automatically checked by Unix tools. Contra: 1. Well, it's change :) What do you think? how much work will this be? what kind of risk will it bring? as in i guess its too late for beta1 .. i guess its not something that forces us to stay at alpha, but will that change alone require another beta before we go to RC? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] build IDs proposal
Hi! how much work will this be? Not much work - I think I can do it in 1 day. what kind of risk will it bring? not much I guess as it will influence only how extensions are loaded - once extension loads, pretty much the deed is done and that code influences nothing. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] build IDs proposal
On Thu, Jan 15, 2009 at 12:06 AM, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 14.01.2009, at 23:22, Stanislav Malyshev wrote: how much work will this be? Very little work, see zend_extension.c line 60, we only have to replace this test and update definition for the default header (zend_extension struct used by each ext). what kind of risk will it bring? None, but it removes many troubles. as in i guess its too late for beta1 .. i guess its not something that forces us to stay at alpha, but will that change alone require another beta before we go to RC? It is not too late for b1. However this change alone does not justify another beta but I think (well I'm sure) that we will have many betas anyway. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] build IDs proposal
how much work will this be? Not much work - I think I can do it in 1 day. Please don't forget to add human-readable error message when the IDs don't match. Better to have different errors for different mismatching parts. It's important because not all administrators are good with understanding realted problems. Maybe some sort of hints on what to do should be there too. -jv -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
