Re: [PHP-DEV] Re: Help with the snaps site
Hi John, I actually kind of liked the branch names instead of just PHP4/PHP5. PHP5 doesn't mean squat to me, I'd prefer to see the branch names as they barely take any more space and yet provide a lot more info. - Tul John Mertic wrote: Hi Chris, I can see where you are coming from. I put together another version of this that entirely uses the PHP CSS templates: http://files.edin.dk/php/installer/snaps-html/index-phptemplate.html It looks and feels more like the main PHP.net site. I also went ahead and changed the branch names to PHP 4, PHP 5, and PHP 6, instead of 4.4.x-dev, etc. I'm curious now which one everyone prefers, the previous one ( http://files.edin.dk/php/installer/snaps-html/index.html ) or the one listed above. John On 5/25/07, Christopher Jones [EMAIL PROTECTED] wrote: On reflection, now I've had lunch, the intent/risks of the snapshots isn't so clear. Maybe a simple change such as making the headings 4.4 Development spelling out Development (no need for the .x anyway), or maybe a brief paragraph description is needed. Also adding a link to http://www.php.net/downloads somewhere might help the googler who lands on the snaps page but wants something stable to use. A problem even with the current snaps page is that the PHP logo doesn't link to php.net. And I'd prefer the snap page had the stand php.net header links. Chris John Mertic wrote: Thanks for the compliments and the suggestion. I've made the whole section underneath each branch in the light blue highlighted color. I agree it makes it much easier to read now. John On 5/25/07, Christopher Jones [EMAIL PROTECTED] wrote: John Mertic wrote: Below is a link to my take on the redesign: http://files.edin.dk/php/installer/snaps-html/index.html (Warning - none of the links on the page go to anywhere) My thinking is keep one set of builds on the main page and then provide a link to previous builds, which we can give an ftp-style listing or make the nicer looking page like above. This keeps the snaps page cleaner since I would think most people would be looking for the latest snap and not necessarily one of the previous 4 ones. Let me know if my approach and design sounds reasonable. Looks really nice. I like the next snap column on the LH side. My only improvement would be to change the horizontal background shading so it encompasses the heading of each section as well as the content, and/or encompasses the Previous Builds line. When I look into the middle section of the page my eyes read from the top of each color band, e.g. I see Previous Builds 5.2.x-dev Source Distribution. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Book: http://tinyurl.com/f8jad -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
John Mertic wrote: Hi Chris, I can see where you are coming from. I put together another version of this that entirely uses the PHP CSS templates: http://files.edin.dk/php/installer/snaps-html/index-phptemplate.html I like it, but how about using BZip2 Tarball and Zip Package etc instead of php5 (...)? -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
On 5/26/07, John Mertic [EMAIL PROTECTED] wrote: Hi Chris, I can see where you are coming from. I put together another version of this that entirely uses the PHP CSS templates: http://files.edin.dk/php/installer/snaps-html/index-phptemplate.html New one looks better, I would prefer this. It looks and feels more like the main PHP.net site. I also went ahead and changed the branch names to PHP 4, PHP 5, and PHP 6, instead of 4.4.x-dev, etc. Would like to see the branch name 4.4.x-dev , 5.5.x-dev, etc. and not PHP4, PHP5. I'm curious now which one everyone prefers, the previous one ( http://files.edin.dk/php/installer/snaps-html/index.html ) or the one listed above. John On 5/25/07, Christopher Jones [EMAIL PROTECTED] wrote: On reflection, now I've had lunch, the intent/risks of the snapshots isn't so clear. Maybe a simple change such as making the headings 4.4 Development spelling out Development (no need for the .x anyway), or maybe a brief paragraph description is needed. Also adding a link to http://www.php.net/downloads somewhere might help the googler who lands on the snaps page but wants something stable to use. A problem even with the current snaps page is that the PHP logo doesn't link to php.net. And I'd prefer the snap page had the stand php.netheader links. Chris John Mertic wrote: Thanks for the compliments and the suggestion. I've made the whole section underneath each branch in the light blue highlighted color. I agree it makes it much easier to read now. John On 5/25/07, Christopher Jones [EMAIL PROTECTED] wrote: John Mertic wrote: Below is a link to my take on the redesign: http://files.edin.dk/php/installer/snaps-html/index.html (Warning - none of the links on the page go to anywhere) My thinking is keep one set of builds on the main page and then provide a link to previous builds, which we can give an ftp-style listing or make the nicer looking page like above. This keeps the snaps page cleaner since I would think most people would be looking for the latest snap and not necessarily one of the previous 4 ones. Let me know if my approach and design sounds reasonable. Looks really nice. I like the next snap column on the LH side. My only improvement would be to change the horizontal background shading so it encompasses the heading of each section as well as the content, and/or encompasses the Previous Builds line. When I look into the middle section of the page my eyes read from the top of each color band, e.g. I see Previous Builds 5.2.x-dev Source Distribution. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Book: http://tinyurl.com/f8jad -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Book: http://tinyurl.com/f8jad -- -- John MerticExplaining a joke is like dissecting a frog: you [EMAIL PROTECTED] understand it better, but the frog dies in the process. -Mark Twain -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- with Regards, Raghubansh
[PHP-DEV] Merging patches to HEAD [ was: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS /ext/standard html.c html.h /ext/standard/tests/strings htmlentities18.phpt ]
Ilia Alshanetsky wrote: On 25-May-07, at 10:11 AM, Hannes Magnusson wrote: On 5/22/07, Ilia Alshanetsky [EMAIL PROTECTED] wrote: iliaa Tue May 22 12:37:01 2007 UTC Added files: (Branch: PHP_5_2) /php-src/ext/standard/tests/strings htmlentities18.phpt Modified files: /php-srcNEWS /php-src/ext/standard html.c html.h Log: [DOC] Added a 4th parameter flag to htmlspecialchars() and htmlentities() that makes the function not encode existing html entities. The feature is disabled by default and can be activated by passing FALSE as the 4th param Is this a PHP 5.2 only feature? Yes. Ilia Alshanetsky Ilia, I would really like to know why you are not merging patches to head? I think this is an unacceptable practice that should be stopped right away. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Merging patches to HEAD [ was: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS /ext/standard html.c html.h /ext/standard/tests/strings htmlentities18.phpt ]
On 5/26/07, Edin Kadribasic [EMAIL PROTECTED] wrote: Ilia, I would really like to know why you are not merging patches to head? I think this is an unacceptable practice that should be stopped right away. It's should be even more unacceptable that people development on the php 5 branch when they instead should develop on head . And then of course merge to branches that is needed. -- regards, Robin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Merging patches to HEAD [ was: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS /ext/standard html.c html.h /ext/standard/tests/strings htmlentities18.phpt ]
Robin Ericsson wrote: On 5/26/07, Edin Kadribasic [EMAIL PROTECTED] wrote: Ilia, I would really like to know why you are not merging patches to head? I think this is an unacceptable practice that should be stopped right away. It's should be even more unacceptable that people development on the php 5 branch when they instead should develop on head . And then of course merge to branches that is needed. The order does not really matter. What matters is that all relevant branches remain in sync. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $var::$static
Hi,
this doesnt work because static vars are bound to his class and are not
inherited by a child class.
maybe this would be work with php6 or a other 5.x version.
(Same behavior like the singleton pattern getInstance() abstract class
stuff)
-- Marco
Hi all,
I'd like to be able to do the following:
?php
class Base {
public static $var = 'hello';
public function someFunc() {
echo self::$var; // Currently maps to Base::$var
echo $this::$var; // Should map to Child::$var
}
}
class Child extends Base {
public static $var = 'hello';
}
$class = 'Child';
$obj = new $class(); // This works.
echo $class::$var; // This doesn't. Should map to Child::$var
?
...in other words: I'd like to be able to access static class
variables from inside an instance of the Base and/or Child classes.
I'd also like to be able to access them dynamically.
($className::$variable)
The only way to do this at the moment (to my knowledge at least) is to
create functions in the Child class that returns its static variables.
The downside of this is that those functions most likely will be very
common (in my case they are) and should therefore belong in the base
class. Hence: $this::$variable
At the moment there is no way to access static variables from outside
of the class dynamically. As a workaround for this I'm currently
creating a temporary instance (new $type()) to access them dynamically
with a __get() function in all the derived child classes.
There are ways to do it with class constants and the constant
functions. But it's not very elegant and class constants can't hold
arrays and/or objects.
I have no idea what the implications would be. Just thought it would
be a nice addition to the language. :) Hope I didn't overlook some
existing PHP feature that already allows me to do this. :|
Cheers,
Bart de Boer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $var::$static (and $className::$staticVar)
I understand... My suggestion would be to map $this to the class name
(of the current instance) if the Scope Resolution Operator '::' is used...
Marco Kaiser wrote:
Hi,
this doesnt work because static vars are bound to his class and are not
inherited by a child class.
maybe this would be work with php6 or a other 5.x version.
(Same behavior like the singleton pattern getInstance() abstract class
stuff)
-- Marco
Hi all,
I'd like to be able to do the following:
?php
class Base {
public static $var = 'hello';
public function someFunc() {
echo self::$var; // Currently maps to Base::$var
echo $this::$var; // Should map to Child::$var
}
}
class Child extends Base {
public static $var = 'hello';
}
$class = 'Child';
$obj = new $class(); // This works.
echo $class::$var; // This doesn't. Should map to Child::$var
?
...in other words: I'd like to be able to access static class
variables from inside an instance of the Base and/or Child classes.
I'd also like to be able to access them dynamically.
($className::$variable)
The only way to do this at the moment (to my knowledge at least) is to
create functions in the Child class that returns its static variables.
The downside of this is that those functions most likely will be very
common (in my case they are) and should therefore belong in the base
class. Hence: $this::$variable
At the moment there is no way to access static variables from outside
of the class dynamically. As a workaround for this I'm currently
creating a temporary instance (new $type()) to access them dynamically
with a __get() function in all the derived child classes.
There are ways to do it with class constants and the constant
functions. But it's not very elegant and class constants can't hold
arrays and/or objects.
I have no idea what the implications would be. Just thought it would
be a nice addition to the language. :) Hope I didn't overlook some
existing PHP feature that already allows me to do this. :|
Cheers,
Bart de Boer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $var::$static
I seem to have been a bit too hasty with my previous reply... You meant
it wouldn't be able to access the static vars of the inherited Base
class?... I think that's a different feature regarding the static access
mechanism currently already in place... I'm only suggesting the ability
to reference classes dynamically some way...
-- Bart
Marco Kaiser wrote:
Hi,
this doesnt work because static vars are bound to his class and are not
inherited by a child class.
maybe this would be work with php6 or a other 5.x version.
(Same behavior like the singleton pattern getInstance() abstract class
stuff)
-- Marco
Hi all,
I'd like to be able to do the following:
?php
class Base {
public static $var = 'hello';
public function someFunc() {
echo self::$var; // Currently maps to Base::$var
echo $this::$var; // Should map to Child::$var
}
}
class Child extends Base {
public static $var = 'hello';
}
$class = 'Child';
$obj = new $class(); // This works.
echo $class::$var; // This doesn't. Should map to Child::$var
?
...in other words: I'd like to be able to access static class
variables from inside an instance of the Base and/or Child classes.
I'd also like to be able to access them dynamically.
($className::$variable)
The only way to do this at the moment (to my knowledge at least) is to
create functions in the Child class that returns its static variables.
The downside of this is that those functions most likely will be very
common (in my case they are) and should therefore belong in the base
class. Hence: $this::$variable
At the moment there is no way to access static variables from outside
of the class dynamically. As a workaround for this I'm currently
creating a temporary instance (new $type()) to access them dynamically
with a __get() function in all the derived child classes.
There are ways to do it with class constants and the constant
functions. But it's not very elegant and class constants can't hold
arrays and/or objects.
I have no idea what the implications would be. Just thought it would
be a nice addition to the language. :) Hope I didn't overlook some
existing PHP feature that already allows me to do this. :|
Cheers,
Bart de Boer
Hi,
this doesnt work because static vars are bound to his class and are not
inherited by a child class.
maybe this would be work with php6 or a other 5.x version.
(Same behavior like the singleton pattern getInstance() abstract class
stuff)
-- Marco
Hi all,
I'd like to be able to do the following:
?php
class Base {
public static $var = 'hello';
public function someFunc() {
echo self::$var; // Currently maps to Base::$var
echo $this::$var; // Should map to Child::$var
}
}
class Child extends Base {
public static $var = 'hello';
}
$class = 'Child';
$obj = new $class(); // This works.
echo $class::$var; // This doesn't. Should map to Child::$var
?
...in other words: I'd like to be able to access static class
variables from inside an instance of the Base and/or Child classes.
I'd also like to be able to access them dynamically.
($className::$variable)
The only way to do this at the moment (to my knowledge at least) is to
create functions in the Child class that returns its static variables.
The downside of this is that those functions most likely will be very
common (in my case they are) and should therefore belong in the base
class. Hence: $this::$variable
At the moment there is no way to access static variables from outside
of the class dynamically. As a workaround for this I'm currently
creating a temporary instance (new $type()) to access them dynamically
with a __get() function in all the derived child classes.
There are ways to do it with class constants and the constant
functions. But it's not very elegant and class constants can't hold
arrays and/or objects.
I have no idea what the implications would be. Just thought it would
be a nice addition to the language. :) Hope I didn't overlook some
existing PHP feature that already allows me to do this. :|
Cheers,
Bart de Boer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $var::$static
Hi,
I agree that $this::$var isn't really logical, since $this is an object
and not a class name. But I do not see why $class::$var shouldn't work,
or $class::$method() for that method. You can also do $function().
Also I want to suggest that brackets can be used more freely. Currently
you can use ${$group . '_myvar'}, but you can't do the same for
functions and classes. It would be great if you could use {$group . '_'
. $fn}() and {get_class($this)}::$var.
The way to solve this problems right now is to use eval('return ' .
get_class($this) . '::$var;') for getting the value. Getting a reference
to the variable to set it, is even more messy. You need to do something
like eval('$cvar = ' . get_class($this) . '::$var;'); $cvar = 'bye';.
Anyway, it is not so nice, but doable in user space fairly easily. So I
don't see why anything needs to be added in PHP 5. It would be nice to
have a better method in PHP 6 though.
From Holland with love,
Arnold
Bart de Boer wrote:
I seem to have been a bit too hasty with my previous reply... You
meant it wouldn't be able to access the static vars of the inherited
Base class?... I think that's a different feature regarding the static
access mechanism currently already in place... I'm only suggesting the
ability to reference classes dynamically some way...
-- Bart
Marco Kaiser wrote:
Hi,
this doesnt work because static vars are bound to his class and are not
inherited by a child class.
maybe this would be work with php6 or a other 5.x version.
(Same behavior like the singleton pattern getInstance() abstract class
stuff)
-- Marco
Hi all,
I'd like to be able to do the following:
?php
class Base {
public static $var = 'hello';
public function someFunc() {
echo self::$var; // Currently maps to Base::$var
echo $this::$var; // Should map to Child::$var
}
}
class Child extends Base {
public static $var = 'hello';
}
$class = 'Child';
$obj = new $class(); // This works.
echo $class::$var; // This doesn't. Should map to Child::$var
?
...in other words: I'd like to be able to access static class
variables from inside an instance of the Base and/or Child classes.
I'd also like to be able to access them dynamically.
($className::$variable)
The only way to do this at the moment (to my knowledge at least) is to
create functions in the Child class that returns its static variables.
The downside of this is that those functions most likely will be very
common (in my case they are) and should therefore belong in the base
class. Hence: $this::$variable
At the moment there is no way to access static variables from outside
of the class dynamically. As a workaround for this I'm currently
creating a temporary instance (new $type()) to access them dynamically
with a __get() function in all the derived child classes.
There are ways to do it with class constants and the constant
functions. But it's not very elegant and class constants can't hold
arrays and/or objects.
I have no idea what the implications would be. Just thought it would
be a nice addition to the language. :) Hope I didn't overlook some
existing PHP feature that already allows me to do this. :|
Cheers,
Bart de Boer
Hi,
this doesnt work because static vars are bound to his class and are not
inherited by a child class.
maybe this would be work with php6 or a other 5.x version.
(Same behavior like the singleton pattern getInstance() abstract class
stuff)
-- Marco
Hi all,
I'd like to be able to do the following:
?php
class Base {
public static $var = 'hello';
public function someFunc() {
echo self::$var; // Currently maps to Base::$var
echo $this::$var; // Should map to Child::$var
}
}
class Child extends Base {
public static $var = 'hello';
}
$class = 'Child';
$obj = new $class(); // This works.
echo $class::$var; // This doesn't. Should map to Child::$var
?
...in other words: I'd like to be able to access static class
variables from inside an instance of the Base and/or Child classes.
I'd also like to be able to access them dynamically.
($className::$variable)
The only way to do this at the moment (to my knowledge at least) is to
create functions in the Child class that returns its static variables.
The downside of this is that those functions most likely will be very
common (in my case they are) and should therefore belong in the base
class. Hence: $this::$variable
At the moment there is no way to access static variables from outside
of the class dynamically. As a workaround for this I'm currently
creating a temporary instance (new $type()) to access them dynamically
with a __get() function in all the derived child classes.
There are ways to do it with class constants and the constant
functions. But it's not very elegant and class constants can't hold
arrays and/or objects.
I have no idea what the implications would be. Just thought it would
be a nice addition to the language. :) Hope I
Re: [PHP-DEV] $var::$static
Arnold Daniels wrote:
Hi,
I agree that $this::$var isn't really logical, since $this is an object
and not a class name. But I do not see why $class::$var shouldn't work,
or $class::$method() for that method. You can also do $function().
Also I want to suggest that brackets can be used more freely. Currently
you can use ${$group . '_myvar'}, but you can't do the same for
functions and classes. It would be great if you could use {$group . '_'
. $fn}() and {get_class($this)}::$var.
The way to solve this problems right now is to use eval('return ' .
get_class($this) . '::$var;') for getting the value. Getting a reference
to the variable to set it, is even more messy. You need to do something
like eval('$cvar = ' . get_class($this) . '::$var;'); $cvar = 'bye';.
Anyway, it is not so nice, but doable in user space fairly easily. So I
don't see why anything needs to be added in PHP 5. It would be nice to
have a better method in PHP 6 though.
From Holland with love,
Arnold
Hi Arnold,
?php
$a = $group . '_' . $fn;
$a();
?
As for get_class($this)::$var it pays to search the mailing list
archives. the static:: keyword is being using in PHP 6 to do exactly
what you want from within a class. Outside of a class, $var::$value
doesn't work yet, but the implementation of static may make it possible
to implement $var::$value as well.
Greg
P.S. The list archives are http://marc.info/?l=php-dev and are searchable
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] virtual_file_ex/filetype
Hello,
the function virtual_file_ex (TSRM/tsrm_virtual_cwd.c:1011) resolves links to
its link target. This may lead to problems when using filtype() on php
compiled with --enable-maintainer-zts.
You can see the arguments passed to virual_lstat as follows:
Breakpoint 1, virtual_lstat (path=0xb7931574 /tmp/link-test, buf=0xbfc973b4,
tsrm_ls=0x87b8018)
at /usr/local/src/php-5.2.2/TSRM/tsrm_virtual_cwd.c:1011
1012if (virtual_file_ex(new_state, path, NULL, CWD_REALPATH)) {
The following is a print of the variable 'new_state':
(gdb) p new_state
$8 = {cwd = 0x891dc80 /tmp/pear, cwd_length = 9}
This is at least an explanation for the behavior on my computer.
Hope I could help.
Best Regards,
Oliver
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
On 5/26/07, Raghubansh [EMAIL PROTECTED] wrote: Would like to see the branch name 4.4.x-dev , 5.5.x-dev, etc. and not PHP4, PHP5. Changed the titles back. Any other comments on this version (http://files.edin.dk/php/installer/snaps-html/index-phptemplate.html), or should we go ahead and put it up there? -- -- John MerticExplaining a joke is like dissecting a frog: you [EMAIL PROTECTED] understand it better, but the frog dies in the process. -Mark Twain -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Merging patches to HEAD [ was: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS /ext/standard html.c html.h /ext/standard/tests/strings htmlentities18.phpt ]
On 26-May-07, at 6:51 AM, Edin Kadribasic wrote: Ilia, I would really like to know why you are not merging patches to head? Unfortunately I don't have as much time to spend on PHP as I'd like and I focus my attention on the aspects of PHP I use and can tests using the dev environments I have. I do not have a ready PHP6 environment and do not have time to test thing with php6 code, with which I do not have as much familiarity. Rather then making commits that may break the builds or spending hours resolving conflicts I focus my attention on PHP5 where fixes and improvements have tangible benefits to users. That said the commits are all public and if someone who is more familiar with php6 code then I can merge them, it would be great. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Merging patches to HEAD [ was: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS /ext/standard html.c html.h /ext/standard/tests/strings htmlentities18.phpt ]
Before you start mumbling about what is acceptable and unacceptable perhaps you should try contributing something to the language aside from the left field commentary. On 26-May-07, at 6:53 AM, Robin Ericsson wrote: On 5/26/07, Edin Kadribasic [EMAIL PROTECTED] wrote: Ilia, I would really like to know why you are not merging patches to head? I think this is an unacceptable practice that should be stopped right away. It's should be even more unacceptable that people development on the php 5 branch when they instead should develop on head . And then of course merge to branches that is needed. -- regards, Robin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Merging patches to HEAD [ was: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS /ext/standard html.c html.h /ext/standard/tests/strings htmlentities18.phpt ]
Ilia, hi, You said at one point (off-list) that it would be a five-minute task to make a list of the patches that haven't been merged to HEAD. It isn't for me, and I've only been recording actual bug fixes in the weeklies. Do you have five minutes spare to create that list and either stick it online somewhere or mail it here? I can check which patches still haven't been merged and pass on those needing attention to folk with the appropriate karma. (i.e. 'not PDO' ;) I think everyone's just going to have to accept it isn't going to get done any other way. - Steph - Original Message - From: Ilia Alshanetsky [EMAIL PROTECTED] To: Edin Kadribasic [EMAIL PROTECTED] Cc: PHP Internals List internals@lists.php.net Sent: Saturday, May 26, 2007 4:38 PM Subject: [PHP-DEV] Re: Merging patches to HEAD [ was: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS /ext/standard html.c html.h /ext/standard/tests/strings htmlentities18.phpt ] On 26-May-07, at 6:51 AM, Edin Kadribasic wrote: Ilia, I would really like to know why you are not merging patches to head? Unfortunately I don't have as much time to spend on PHP as I'd like and I focus my attention on the aspects of PHP I use and can tests using the dev environments I have. I do not have a ready PHP6 environment and do not have time to test thing with php6 code, with which I do not have as much familiarity. Rather then making commits that may break the builds or spending hours resolving conflicts I focus my attention on PHP5 where fixes and improvements have tangible benefits to users. That said the commits are all public and if someone who is more familiar with php6 code then I can merge them, it would be great. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
Way ahead of you :) http://snaps.php.net/newsnaps.php Edin John Mertic wrote: On 5/26/07, Raghubansh [EMAIL PROTECTED] wrote: Would like to see the branch name 4.4.x-dev , 5.5.x-dev, etc. and not PHP4, PHP5. Changed the titles back. Any other comments on this version (http://files.edin.dk/php/installer/snaps-html/index-phptemplate.html), or should we go ahead and put it up there? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
The new snaps site is up and running. I want to thank John Mertic for the nice work the design and everyone for coming with helpful suggestions. Edin P.S. this file is in the cvs as systems/snaps_index.php so any modification suggestions would be best sent as patches to this file. Edin Kadribasic wrote: Way ahead of you :) http://snaps.php.net/newsnaps.php Edin John Mertic wrote: On 5/26/07, Raghubansh [EMAIL PROTECTED] wrote: Would like to see the branch name 4.4.x-dev , 5.5.x-dev, etc. and not PHP4, PHP5. Changed the titles back. Any other comments on this version (http://files.edin.dk/php/installer/snaps-html/index-phptemplate.html), or should we go ahead and put it up there? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $var::$static
Hi again,
I'm aware that you can do `$a = $group . '_' . $fn; $a();`, but you can
do `$b = $group . '_' . $var; echo $$b;` as well as `echo ${$group . '_'
. $var}`. It's a mater of style, not if there is any way to get it done.
Yes I've read about 'static::' some time ago, but forgot about it.
Thanks for pointing it out. I (unfortunately) took that as an example,
but it wasn't the case I wanted to make.
To my opinion, the ease with which you can use output of an expression
to be used as name of a variable is wonderful. The code is so much
clearer than when you have to create all kind of temporary variables
and/or use eval. I think it is unfortunate that the same logic isn't
available for functions and classes.
Best regards,
Arnold
Gregory Beaver wrote:
Arnold Daniels wrote:
Hi,
I agree that $this::$var isn't really logical, since $this is an object
and not a class name. But I do not see why $class::$var shouldn't work,
or $class::$method() for that method. You can also do $function().
Also I want to suggest that brackets can be used more freely. Currently
you can use ${$group . '_myvar'}, but you can't do the same for
functions and classes. It would be great if you could use {$group . '_'
. $fn}() and {get_class($this)}::$var.
The way to solve this problems right now is to use eval('return ' .
get_class($this) . '::$var;') for getting the value. Getting a reference
to the variable to set it, is even more messy. You need to do something
like eval('$cvar = ' . get_class($this) . '::$var;'); $cvar = 'bye';.
Anyway, it is not so nice, but doable in user space fairly easily. So I
don't see why anything needs to be added in PHP 5. It would be nice to
have a better method in PHP 6 though.
From Holland with love,
Arnold
Hi Arnold,
?php
$a = $group . '_' . $fn;
$a();
?
As for get_class($this)::$var it pays to search the mailing list
archives. the static:: keyword is being using in PHP 6 to do exactly
what you want from within a class. Outside of a class, $var::$value
doesn't work yet, but the implementation of static may make it possible
to implement $var::$value as well.
Greg
P.S. The list archives are http://marc.info/?l=php-dev and are searchable
Re: [PHP-DEV] Re: Still having lstat trouble
Ok, I think I found the problem, as Oliver pointed me on something in the thread titled virtual_file_ex/filetype. When PHP is build with --enable-maintainer-zts mode, then this lstat, and some others too, is broken. I have build 2 PHP installations(PHP-5.2.3RC1), Both with the same configuration options, except that I build the first without --enable-maintainer-zts, and the second one with. The first one does execute the code as expected, while the second code doesn't. It returns the same for all filesystems that were actually allowing symlinks, no matter which options used: file not a link same So, thank Oliver! Tijnema -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Still having lstat trouble
I found my problem as well. I am running apache2 prefork, but the headers for apache2-mpm ware installed instead. I guess Ubuntu messed up with the distro update. Thanks for all your help, Arnold Tijnema wrote: Ok, I think I found the problem, as Oliver pointed me on something in the thread titled virtual_file_ex/filetype. When PHP is build with --enable-maintainer-zts mode, then this lstat, and some others too, is broken. I have build 2 PHP installations(PHP-5.2.3RC1), Both with the same configuration options, except that I build the first without --enable-maintainer-zts, and the second one with. The first one does execute the code as expected, while the second code doesn't. It returns the same for all filesystems that were actually allowing symlinks, no matter which options used: file not a link same So, thank Oliver! Tijnema -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Still having lstat trouble
Arnold Daniels wrote: I found my problem as well. I am running apache2 prefork, but the headers for apache2-mpm ware installed instead. I guess Ubuntu messed up with the distro update. This explains it all. Our Apache 2 servers uses worker mpm. Gentoo builds the cli with zts too. That is why our cli and apache 2 returned wrong data. So, it this a bug in ZTS? Or do we have to live with this? -- Brian Moon Senior Developer -- http://dealnews.com/ It's good to be cheap =) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Merging patches to HEAD [ was: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS /ext/standard html.c html.h /ext/standard/tests/strings htmlentities18.phpt ]
You ask and you shall receive :-) Thanks. I guess :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] late static binding
Hi all!
I've been researching the current status of late static binding, and I came
across this mailing list with a few topics on this subject. After doing the
reading, I had a couple of questions that maybe one of the experienced
parties involved could help clear up for me. Basically, I am wondering if
anybody has tossed around the idea of having a scope of child::, just like
there is one of parent:: (for the class that is inherited from) and self::
(the current class). I understand that the idea has been discussed about
this:: or static::, but those two suggestions -- as fine as they are -- just
seem counter intuitive. this has always been used in the same context as
self::, but for instantiated objects, and static:: seems redundant (at least
to me). Is there a reason why this:: would be preferred over child::?
My second question on this topic would be how hard would it be to create a
child scope in the Zend Engine? Since I am not a very experienced C
programmer, this may be a naive question, but if Zend is smart enough to
know who the inherited class object is, could it be much more difficult to
know who did the inheriting?
I mainly wanted to just add my Two Cents to the discussion, because as I get
more and more into using PHP5 for OO programming, I am finding it more
important to have late static binding.
And, since I've seen the request made for examples of real-world use-cases,
I am trying to build a set of classes that would allow me to work with the
super globals without actually directly touching them. If we had something
like a child:: scope, then I could write code that looked like this:
class MyGlobals
{
static public function get($name)
{
// Each child would implement their own version of filter
// that would handle the type of data that it has.
child::filter(child::$global[$name];
// Do common stuff here before returning value
}
}
class FilesGlobal extends MyGlobals
{
// This is so the parent class will know where to look for the
information we need. Each class would have this declaration.
static protected $global = $_FILES;
static protected filter($value)
{
// Do file-related filtering here (i.e., validate filename is valid,
exists, etc) or throw an exception
// on failure.
}
}
Instead, I have to write 9 separate classes, with each of the classes having
all the same functions that are written almost exactly the same. So, for
example, if I have 100 lines of code in one class, my overall set of classes
would contain almost 800 lines of duplicate code. I hope this illustrates
the appeal for this feature. It is a maintenance nightmare! :)
I know it has been said by some that this functionality is rare, but I would
like to say that the functionality was just never needed until recently.
There are many cases that I can think of that this would be helpful, and if
need be, I would be more than happy to write more examples. I think,
however, that the above example shows a good situation for the parent class
to be able to see the child class.
Regardless of the direction taken with this issue, I would like thank all of
the developers who have made PHP so great. :)
- Ken
--
It looked like something resembling white marble, which was
probably what it was: something resembling white marble.
-- Douglas Adams, The Hitchhikers Guide to the Galaxy
Re: [PHP-DEV] late static binding
Ken Stanley wrote: I've been researching the current status of late static binding, and I came across this mailing list with a few topics on this subject. After doing the reading, I had a couple of questions that maybe one of the experienced parties involved could help clear up for me. Basically, I am wondering if anybody has tossed around the idea of having a scope of child::, just like there is one of parent:: (for the class that is inherited from) and self:: (the current class). I understand that the idea has been discussed about this:: or static::, but those two suggestions -- as fine as they are -- just seem counter intuitive. this has always been used in the same context as self::, but for instantiated objects, and static:: seems redundant (at least to me). Is there a reason why this:: would be preferred over child::? It appears that all you are suggesting that is different from what has been discussed previously is purely syntactical. In that regard I would have to say that while neither this:: or static:: are jaw-droppers, child:: seems somewhar counter-intuitive to me. From a purely semantical standpoint, parent:: and self:: work because there is only ever one. On the other hand it seems like it would be somewhat confusing to a developer not aware of the syntax to figure out what child:: would mean. A class could have 'n' number of children and while I realize that it is not really what the late static binding is about it still seems awkward. My second question on this topic would be how hard would it be to create a child scope in the Zend Engine? Since I am not a very experienced C programmer, this may be a naive question, but if Zend is smart enough to know who the inherited class object is, could it be much more difficult to know who did the inheriting? There is (with as much time as has passed this may be more accurately represented as was) a working patch to implement late static binding. I did some early work on it and it was then rewritten to store the required information in the proper places. If I recall correctly it was left at the point of someone needing to determine the performance impact of the patch and come up with solid use cases. I know it has been said by some that this functionality is rare, but I would like to say that the functionality was just never needed until recently. There are many cases that I can think of that this would be helpful, and if need be, I would be more than happy to write more examples. I think, however, that the above example shows a good situation for the parent class to be able to see the child class. The term late static binding is slightly more rare than the functionality itself. There are a few other languages that implement similar concepts. I do know the ball was left firmly in my court on this issue last year and I also know that there has been continued interest from the php userbase about such a feature. If there is still support for it among the core developers I would be interested in taking up the issue again, reviewing and ensuring the most recent patch is still adequate as it relates to head, and determining the performance impact of the patch. -- Mike Lively http://www.digitalsandwich.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Fixing PECL + Core
Just to add my experience (even though the original poster explicitly asked for single extensions not to be mentioned) from a not-completely-unrelated problem: some extensions have an internal version number that is not always updated when the userland API of said extension is changed - see eg. Json and the recent change of behavior on decoding scalar values. This makes it very hard for people maintaining php libraries to code defensively and test the version in use to enable workarounds: - the extension version number is useless (if not managed correctly) - the php version number is useless, since the extension might have been downloaded and compiled from pecl and not correspond to the version that is distributed with the core The only option left in this situation is to test the functionality needed first, then use it, much as it is done in js - a very sad state of things... (of course I would not recommend disabling upgrade / backport of a php extension from pecl as a solution) The fact that the extension lives in both pecl and core and the two might be slightly out of sync does not help at all when trying to find out the cause of regressions... Bye Gaetano -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] late static binding
On 5/26/07, Mike Lively [EMAIL PROTECTED] wrote: It appears that all you are suggesting that is different from what has been discussed previously is purely syntactical. In that regard I would have to say that while neither this:: or static:: are jaw-droppers, child:: seems somewhar counter-intuitive to me. From a purely semantical standpoint, parent:: and self:: work because there is only ever one. On the other hand it seems like it would be somewhat confusing to a developer not aware of the syntax to figure out what child:: would mean. A class could have 'n' number of children and while I realize that it is not really what the late static binding is about it still seems awkward. Yes, I was asking purely for syntactical reasons, but you raise a very interesting point that I did not take wholly into consideration. While my example was meant for multiple children, I did not realize how much more complicated that would become. The term late static binding is slightly more rare than the functionality itself. There are a few other languages that implement similar concepts. I do know the ball was left firmly in my court on this issue last year and I also know that there has been continued interest from the php userbase about such a feature. If there is still support for it among the core developers I would be interested in taking up the issue again, reviewing and ensuring the most recent patch is still adequate as it relates to head, and determining the performance impact of the patch. I hope the support is still there, and if you do release a patch for it, I would be more than happy to help test it. Thank you for your time in responding to my questions. You have definately given me some food for thought. :) -- It looked like something resembling white marble, which was probably what it was: something resembling white marble. -- Douglas Adams, The Hitchhikers Guide to the Galaxy
Re: [PHP-DEV] Documenting the Zend2 extension API
On May 8, 2007, at 2:59 PM, Philip Olson wrote: Hi all, just wanted to give you a heads-up that I'm still working on this project; it took me awhile to get the tools properly set up, but I'm plugging away at DocBook XML now, and I'll have a few patches to send in soon, I think. Thanks for all the advice so far! Hello Gwynne, This is excellent news, and feel free to write the doc list if you have any questions and/or the IRC channels on efnet (#php.pecl and #php.doc). As far as information on the topic goes, let's start a list of the current landscape (with ideas to steal from): - The official docs: http://php.net/manual/internals - CodeGen_PECL: http://pear.php.net/package/codegen_pecl - A few tutorials: http://devzone.zend.com/public/view/tag/extension - The book: Extending and Embedding PHP by Sara Golemon - Many README files in php-src: http://cvs.php.net/viewvc.cgi/php-src/ - A few talks: http://talks.php.net/index.php/Internals - A nice talk: http://netevil.org/talks/furlong-golemon-extending- php.pdf - More talks: http://talks.somabo.de/ - A nice talk: http://talks.somabo.de/ 200610_zend_conf_php_extension_development.pdf - A few examples: http://people.apache.org/~nabeel/php/examples/ Also, let's create a FAQ section dedicated to the topic of extension writing. This list of links has been extremely helpful to me, Philip; I appreciate it a lot :). I'm embarassed to say I came down with a bit of writer's block lately, so I don't have any patches to send in yet, unfortunately. However, I would like the opinion of the list on the avenue I've chosen. Basically, it's my estimation that the existing internals documentation in the manual is not organized very well, nor lends itself to updating with any manner of ease. The material I've been writing is a new section dedicated to the API of ZE2, rather than trying to consolidate all the information for ZE1 (outdated) and ZE3 (still changing almost every day). My preliminary outline for the content looks like this (yanked out of my diffs for manual.xml.in and subject to change): part id=internals2 titleInternals2;/title internals2.intro; internals2.buildsys.index; !-- configure options, ext_skel, config.m4, config.w32, static vs dynamic builds -- internals2.structure.index; !-- ext_skel, module structure, globals, lifecycle, tests -- internals2.memory.index; !-- management, persistence, TSRM -- internals2.variables.index; !-- zval, hashtable, references, constants -- internals2.functions.index; !-- defining, arguments, return values, passthru, aliasing -- internals2.objects.index;!-- classes, inheritance, properties, methods, method-function mapping -- internals2.resources.index; !-- defining, creating, retrieving, destroying -- internals2.ini.index;!-- defining, retrieving, changing -- internals2.streams.index;!-- using, wrappers, contexts, filters -- !-- grab the PDO section from Internals; here? -- internals2.apiref.index; !-- full index of all APIs, constants, macros, etc. -- internals2.ze1.index;!-- quick list of major differences, short discussion re: OOP -- internals2.ze3.index;!-- quick discussion of major changes, some details on Unicode -- /part My thinking is to document ZE2 completely, since the differences between 1 and 2 are small enough for the existing internals section to be of use to anyone writing for 1, and 3 can be more fully documented later (something I'm willing to take on as well). If I'm given a thumbs-down on this way of doing things, I'll take the material I've written already and use it to update the existing internals section, but I think this method has the best chance of giving people the truly comprehensive online reference we've lacked for extension writing up to this point. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
