[PHP-DEV] before beta 2
Marcus Börger
In no particular order these are the things i think should be done before
releasing the next php 5 beta version:
- Include SPL (forach/array hooking).
- Implement overloading as suggested by Sterling.
- Typehinting with '= NULL' to allow NULL values as discussed
- Array and resource type hinting (patch at least for arrays is ready
and resources can easily be affed)
- Typehinting for return values? This may be usefule especially when working
with interfaces.
- Fix __clone() visibility. When implementing singletons we must forbid calling
__clone() by making it private (private function __clone() is the same to
singletons as private function __construct() to factories). Also the clone
mechanism must ensure the new object has all properties defined in the class.
The current implementation doesn't do so what contradicts the inheritance
model. The following example show both errors:
php -r 'class t {var $x; private function __clone() {} }; $a = new t; $b = $a->__clone(); var_dump($a);var_dump($b);'
object(t)#1 (1) {
["x"]=>
NULL
}
object(t)#2 (0) {
}
- Complete work on exceptions and find a solution on when to throw exceptions
and when to use errors.
I still do not see any BC problems with making try/catch blocks to convert
E_WARING, E_NOTICE & E_ERROR to exceptions (assumed the problemntaic E_ERRORS
are changed to E_CORE or such). Why no BC? Simply becuase using try/catch
with old libs and relying on there error capturing is an antilogy in itself.
Especially when thinking about the very limited capabilities in handling
errors the old way.
- Discuss the package proposal and whether we want it or not. We saw that
namespaces didn't really fit in our needs and that they are very problematic.
To tell the truth some here are sure they can't be implemented correct. The
ones thinking the they would obviosly had another idea of them. So let us not
make the same mistake again and make instead sure we are all talking about
the same thing in the same language.
- Finally decide whether we want any other oo feature like aggregation,
delegation or what ever. From my point of view they are nice but not
necessary and will cause more development trouble then they will bring
advantage to the user. So don't lets spend any more efforts in this area.
- Most parts of the language are case insensitive, however some parts are
not. For instance __construct, __clone,...
- Move snprintf.c/spprintf.c into the engine.
- Fix static class members. If the are public they need to be accessible from
outside the class. If they have an initial value this value should be used
and the keyword var should be working as well.
php -r 'class t { static public $p = "x";}; $t = new t; var_dump($t->p);'
php -r 'class t { static var $p = "x";}; $t = new t; var_dump($t->p);'
php -r 'class t { static public $p = "x";}; echo $t::p;'
To make this clear: $t->p would add a dynamic propery to instance t while we
want to access the static property p which can only be achieved by a
different notation which should be <class>'::'<static_member>.
- Do we want static methods to be overwritable?
php -r 'class t {static function x(){}}; class y {static function x(){}};'
- We need to be able to declare method flags from function table for classes
(static/public/protected/private/final).
- Plug some memleaks.
--
Best regards,
Marcus mailto:marcus....@post.rwth-aachen.de
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jon Parise
> In no particular order these are the things i think should be done before
> releasing the next php 5 beta version:
Without going into detail on any of these specific items, I think that
the only work that should be undertaken between now and the release of
PHP 5 is cleanup and bug fixing. There's plenty of that to go around,
and while I realize that everyone wants to get their pet feature added
to or expanded in PHP 5, we need to be realistic.
Any of the items that include the words "add" or "integrate" should be
left for 5.1. Any items marked as "complete" or "finish" are open for
debate. Any items marked as "fix" should be addressed as soon as
possible.
--
Jon Parise (j...@php.net) :: The PHP Project (http://www.php.net/)
Sterling Hughes
>
> > On Mon, Jun 30, 2003 at 02:28:35AM +0200, Marcus Brger wrote:
> >
> > > In no particular order these are the things i think should be done before
> > > releasing the next php 5 beta version:
> >
> > Without going into detail on any of these specific items, I think that
> > the only work that should be undertaken between now and the release of
> > PHP 5 is cleanup and bug fixing. There's plenty of that to go around,
> > and while I realize that everyone wants to get their pet feature added
> > to or expanded in PHP 5, we need to be realistic.
Jon, the overloading issues were left to beta 2, this was already agreed
upon. Its still a long way to a release (I'd guestimate 6-9 months).
The beta is not at this point solid from an API perspective. But since
you seem to think a lot needs fixing up - what would you like fixed up?
What's not working for you atm? Marcus is, btw, not proposing new
features, just completing the existing feature, integrated overloading.
> >
> > Any of the items that include the words "add" or "integrate" should be
> > left for 5.1. Any items marked as "complete" or "finish" are open for
> > debate. Any items marked as "fix" should be addressed as soon as
> > possible.
> >
There won't be truly drastic internals rewrites at this point, but we
are not 100% feature complete. Things like a modified API for
overloading, or clarifications in the type hint model are certainly
valid for consideration in the beta process. There will of course be
lots of bugfixing, but I don't think we should be overly strict at this
point.
-Sterling
> >
--
Good judgement comes from experience, and experience comes from
bad judgement.
- Fred Brooks
Dan Kalowsky
I have to agree with your thinking as well.
Although to the rest of internals, a plea. Can we please wait until
after a weekend to send out release notifications?
On Sunday, June 29, 2003, at 08:59 PM, Jon Parise wrote:
> On Mon, Jun 30, 2003 at 02:28:35AM +0200, Marcus Brger wrote:
>
>> In no particular order these are the things i think should be done
>> before
>> releasing the next php 5 beta version:
>
> Without going into detail on any of these specific items, I think that
> the only work that should be undertaken between now and the release of
> PHP 5 is cleanup and bug fixing. There's plenty of that to go around,
> and while I realize that everyone wants to get their pet feature added
> to or expanded in PHP 5, we need to be realistic.
>
> Any of the items that include the words "add" or "integrate" should be
> left for 5.1. Any items marked as "complete" or "finish" are open for
> debate. Any items marked as "fix" should be addressed as soon as
> possible.
>
> --
> Jon Parise (j...@php.net) :: The PHP Project (http://www.php.net/)
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>---------------------------------------------------------------<
Dan Kalowsky "Momma take this badge offa me,
http://www.deadmime.org/~dank I can't use it anymore."
dank...@aps-deadmime.org - "Knockin on Heavens Door",
kalo...@php.net Bob Dylan
Rasmus Lerdorf
from what most of the world expects from a beta. We have cleaned up some
aspects or our versioning and I was hoping we could clean this up as well.
But I guess not. So, at the very least we need a versioning FAQ where we
explain that a PHP beta is what most would consider an alpha, and the PHP
release candidates is basically our beta stage.
-Rasmus
Dan Kalowsky
concepts others understand them as. AKA why not just stop calling it a
BETA, and refer to it as an ALPHA? At least users would recognize what
this is.
>---------------------------------------------------------------<
Dan Kalowsky "Cause fear is strong and love's
http://www.deadmime.org/~dank for everyone, who isn't me."
dank...@aps-deadmime.org - "Burden In My Hand",
kalo...@php.net Soundgarden
Andi Gutmans
In my opinion beta 1 should be labeled as a beta. The fact that we are=20
fixing a few features doesn't mean it's alpha. I know what the definition=20
of alpha is but in real life most beta's do end up having quite a few code=
=20
changes before release.
I agree that we should try and feature freeze as much as possible right=20
now. I'd like to see PHP 5 out before the 6-9 month period Sterling=20
mentioned. I think we can probably do it within about 4 months if we don't=
=20
mess with the code too much and listen to the feedback of people who are=20
starting to play around with it.
In my opinion, half the stuff listed by Marcus should wait for PHP 5.1=20
(which can be released very quickly after PHP 5):
- Include SPL (forach/array hooking) (although we can discuss it and=20
re-evaluate this once we finalize what we want).
- Typehinting for return values? This may be useful especially when working
with interfaces. (Not sure about this but I think it can wait).
- Complete work on exceptions and find a solution on when to throw=
exceptions
and when to use errors. (as I said I think we should keep it purely in=20
user-land until we see how people end up using exceptions and we get enough=
=20
feedback. I haven't heard any ideas here which are rock solid yet.).
- Discuss the package proposal and whether we want it or not. (Don't think=
=20
this is for PHP 5).
- Finally decide whether we want any other oo feature like aggregation,
delegation or what ever. (-1 too)
I didn't understand the following:
- We need to be able to declare method flags from function table for classes
(static/public/protected/private/final).
The rest of the stuff (which are mainly bug fixes) should be addressed.
Andi
At 02:28 AM 30/6/2003 +0200, Marcus B=F6rger wrote:
>Hello 'internals',
>
>In no particular order these are the things i think should be done before
>releasing the next php 5 beta version:
>
>- Include SPL (forach/array hooking).
>
>- Implement overloading as suggested by Sterling.
>
>- Typehinting with '=3D NULL' to allow NULL values as discussed
>
>- Array and resource type hinting (patch at least for arrays is ready
> and resources can easily be affed)
>
>- Typehinting for return values? This may be usefule especially when=
working
> with interfaces.
>
>- Fix __clone() visibility. When implementing singletons we must forbid=20
>calling
> __clone() by making it private (private function __clone() is the same=
to
> singletons as private function __construct() to factories). Also the=
clone
> mechanism must ensure the new object has all properties defined in the=
=20
> class.
> The current implementation doesn't do so what contradicts the=
inheritance
> model. The following example show both errors:
> php -r 'class t {var $x; private function __clone() {} }; $a =3D new t;=
=20
> $b =3D $a->__clone(); var_dump($a);var_dump($b);'
> object(t)#1 (1) {
> ["x"]=3D>
> NULL
> }
> object(t)#2 (0) {
> }
>
>- Complete work on exceptions and find a solution on when to throw=
exceptions
> and when to use errors.
> I still do not see any BC problems with making try/catch blocks to=
convert
> E_WARING, E_NOTICE & E_ERROR to exceptions (assumed the problemntaic=20
> E_ERRORS
> are changed to E_CORE or such). Why no BC? Simply becuase using=
try/catch
> with old libs and relying on there error capturing is an antilogy in=20
> itself.
> Especially when thinking about the very limited capabilities in handling
> errors the old way.
>
>- Discuss the package proposal and whether we want it or not. We saw that
> namespaces didn't really fit in our needs and that they are very=20
> problematic.
> To tell the truth some here are sure they can't be implemented correct.=
The
> ones thinking the they would obviosly had another idea of them. So let=
=20
> us not
> make the same mistake again and make instead sure we are all talking=
about
> the same thing in the same language.
>
>- Finally decide whether we want any other oo feature like aggregation,
> delegation or what ever. From my point of view they are nice but not
> necessary and will cause more development trouble then they will bring
> advantage to the user. So don't lets spend any more efforts in this=
area.
>
>- Most parts of the language are case insensitive, however some parts are
> not. For instance __construct, __clone,...
>
>- Move snprintf.c/spprintf.c into the engine.
>
>- Fix static class members. If the are public they need to be accessible=
from
> outside the class. If they have an initial value this value should be=
used
> and the keyword var should be working as well.
> php -r 'class t { static public $p =3D "x";}; $t =3D new t;=
var_dump($t->p);'
> php -r 'class t { static var $p =3D "x";}; $t =3D new t;=
var_dump($t->p);'
> php -r 'class t { static public $p =3D "x";}; echo $t::p;'
> To make this clear: $t->p would add a dynamic propery to instance t=20
> while we
> want to access the static property p which can only be achieved by a
> different notation which should be <class>'::'<static_member>.
>
>- Do we want static methods to be overwritable?
> php -r 'class t {static function x(){}}; class y {static function=
x(){}};'
>
>- We need to be able to declare method flags from function table for=
classes
> (static/public/protected/private/final).
>
>- Plug some memleaks.
>
>--
>Best regards,
> Marcus mailto:marcus....@post.rwth-aachen.de
>
>
Andi Gutmans
>Hey,
>
>In my opinion beta 1 should be labeled as a beta. The fact that we are
>I agree that we should try and feature freeze as much as possible right
>
>In my opinion, half the stuff listed by Marcus should wait for PHP 5.1
>- Include SPL (forach/array hooking) (although we can discuss it and
After Sterling reminded me that I did say that this should be considered
for PHP 5 I'll clarify what I meant. What I meant by re-evaluating is that
if everything falls in properly we should re-evaluate the patch before PHP 5.
Let's see another iteration of the spec with pretty names and then decide
:) Also, how are the benchmarks? What is slowed down and by how much? (it
might very well be worth it but I'd like to know more or less). Last but
not least, are there any things which won't work with this such as foreach
with references and other problems?
Andi
Andi Gutmans
Andi
At 07:15 AM 30/6/2003 +0200, Sebastian Bergmann wrote:
>Jon Parise wrote:
> > Without going into detail on any of these specific items, I think that
> > the only work that should be undertaken between now and the release of
> > PHP 5 is cleanup and bug fixing.
>
> One thing that is IMHO essential for the PHP 5.0.0 is the Reflection
> API on which George and Andrei work.
>
>--
>Sebastian Bergmann
>http://sebastian-bergmann.de/ http://phpOpenTracker.de/
>
>Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
Sebastian Bergmann
> Do you have the URL of the docs?
The current one would be
http://www.sebastian-bergmann.de/stuff/reflection-update.png
I re-posted Andrei's document a couple of days ago and made the above
diagram at the same time.
Derick Rethans
> I agree. I think the beta was extremely premature, but now that it is out
> we are on a release track as far as I am concerned. Beta in my view means
> feature-complete full-steam ahead for release. And that means bug fixes
> only from here on and it also means a PHP_5_0 branch.
I don't think this is fair because some things were left out "because
there would be a beta 2 anyway".
Derick
--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
-------------------------------------------------------------------------
Derick Rethans http://derickrethans.nl/
International PHP Magazine http://php-mag.net/
-------------------------------------------------------------------------
Andi Gutmans
>Andi Gutmans wrote:
> > Do you have the URL of the docs?
>
> The current one would be
>
> http://www.sebastian-bergmann.de/stuff/reflection-update.png
>
> I re-posted Andrei's document a couple of days ago and made the above
> diagram at the same time.
Can you repost the docs?
(Nice diagram :)
Andi
Sterling Hughes
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
> >>>> In no particular order these are the things i think should be done
> >>>> before
> >>>> releasing the next php 5 beta version:
> >>>
> >>> Without going into detail on any of these specific items, I think
> >>> that
> >>> the only work that should be undertaken between now and the release
> >>> of
> >>> PHP 5 is cleanup and bug fixing. There's plenty of that to go
> >>> around,
> >>> and while I realize that everyone wants to get their pet feature
> >>> added
> >>> to or expanded in PHP 5, we need to be realistic.
> >>>
> >>> Any of the items that include the words "add" or "integrate" should
> >>> be
> >>> left for 5.1. Any items marked as "complete" or "finish" are open
> >>> for
> >>> debate. Any items marked as "fix" should be addressed as soon as
> >>> possible.
> >>>
> >>> --
> >>> Jon Parise (j...@php.net) :: The PHP Project (http://www.php.net/)
> >>>
> >>> --
> >>> PHP Internals - PHP Runtime Development Mailing List
> >>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >>> ---------------------------------------------------------------<
> >> Dan Kalowsky "Momma take this badge offa me,
> >> http://www.deadmime.org/~dank I can't use it anymore."
> >> dank...@aps-deadmime.org - "Knockin on Heavens Door",
> >> kalo...@php.net Bob Dylan
> >>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >---------------------------------------------------------------<
> Dan Kalowsky "Cause fear is strong and love's
> http://www.deadmime.org/~dank for everyone, who isn't me."
> dank...@aps-deadmime.org - "Burden In My Hand",
> kalo...@php.net Soundgarden
--
"Programming today is a race between software engineers stirring to
build bigger and better idiot-proof programs, and the universe trying
to produce bigger and better idiots. So far, the universe is winning."
- Unknown
Sebastian Bergmann
> Can you repost the docs?
Andrei's document
http://www.sebastian-bergmann.de/stuff/reflection.txt
and my diagram for it
http://www.sebastian-bergmann.de/stuff/reflection.png
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
Marcus Börger
Monday, June 30, 2003, 8:10:30 AM, you wrote:
AG> At 07:43 AM 30/6/2003 +0200, Andi Gutmans wrote:
>>Hey,
>>
>>In my opinion beta 1 should be labeled as a beta. The fact that we are
>>fixing a few features doesn't mean it's alpha. I know what the definition
>>of alpha is but in real life most beta's do end up having quite a few code
>>changes before release.
>>I agree that we should try and feature freeze as much as possible right
>>now. I'd like to see PHP 5 out before the 6-9 month period Sterling
>>mentioned. I think we can probably do it within about 4 months if we don't
>>mess with the code too much and listen to the feedback of people who are
>>starting to play around with it.
>>
>>In my opinion, half the stuff listed by Marcus should wait for PHP 5.1
>>(which can be released very quickly after PHP 5):
>>- Include SPL (forach/array hooking) (although we can discuss it and
>>re-evaluate this once we finalize what we want).
AG> After Sterling reminded me that I did say that this should be considered
AG> for PHP 5 I'll clarify what I meant. What I meant by re-evaluating is that
AG> if everything falls in properly we should re-evaluate the patch before PHP 5.
AG> Let's see another iteration of the spec with pretty names and then decide
AG> :) Also, how are the benchmarks? What is slowed down and by how much? (it
AG> might very well be worth it but I'd like to know more or less). Last but
AG> not least, are there any things which won't work with this such as foreach
AG> with references and other problems?
According to foreach hooking
a) I couldn't make out any problem that isn't fixed right now
b) When included into the engine the differences are
3 additional comparisons in FE_RESET (2 pointers, 1 integer)
1 additional check in FE_FETCH (integer)
2 additional checks and a complex fetch in (SWITCH_FREE)
-> that should be near to zero impact.
In the early stages when it wasn't that optimized it was already near
unmeasurable.
c) IT makes no sense letting me do more work in here. I really can't see what
i can do more. Of the new oo things it is right now one of the best
documented and tested. So others have to test and report :-)
Array hooking is somewhat different. The impact is higher and it isn't
really optimized right now. That's why i made it optional. The question here
is whether we want it or not. But again being integrated in the engine the
overhead can be reduced to a level described in foreach hooking.
Best regards,
Marcus mailto:he...@php.net
Zeev Suraski
>On Sun, 29 Jun 2003, Rasmus Lerdorf wrote:
>
> > I agree. I think the beta was extremely premature, but now that it is out
> > we are on a release track as far as I am concerned. Beta in my view means
> > feature-complete full-steam ahead for release. And that means bug fixes
> > only from here on and it also means a PHP_5_0 branch.
>
>I don't think this is fair because some things were left out "because
>there would be a beta 2 anyway".
Needless to say I don't think that the beta was extremely premature but
quite the contrary, and I think that the ideas that were left for beta 2
will be reviewed again before beta 2 (there weren't too many of them, and I
think all of them were in Andi's sub-list of Marcus' list, that I find
quite reasonable). It doesn't mean that all of them will make it into PHP
5, since I consider the time-frame to be pretty important, especially
considering how much time we lost with this project, and how many people
are waiting for it. It doesn't come to say that all of them will make it
into PHP at all, by the way - some of them are open questions...
Zeev
Zeev Suraski
>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.
I agree with every word...
Jon Parise
> > > Without going into detail on any of these specific items, I think that
> > > the only work that should be undertaken between now and the release of
> > > PHP 5 is cleanup and bug fixing. There's plenty of that to go around,
> > > and while I realize that everyone wants to get their pet feature added
> > > to or expanded in PHP 5, we need to be realistic.
>
> Jon, the overloading issues were left to beta 2, this was already agreed
> upon.
Okay. I admit that I don't know much about that feature.
> Its still a long way to a release (I'd guestimate 6-9 months). The
> beta is not at this point solid from an API perspective. But since
> you seem to think a lot needs fixing up - what would you like fixed
> up?
I could have phrased that better. I meant that, now that PHP 5 is on
a release track, there's plenty of work to be done with regard to QA
testing and responding to testing feedback / bug reports.
If PHP 5 really is 6-9 months away than I agree with Rasmus: this beta
was premature and gives the false impression that PHP 5 is nearing a
final release.
> What's not working for you atm? Marcus is, btw, not proposing new
> features, just completing the existing feature, integrated
> overloading.
Everything is working well for me now, and I'd prefer to keep it that
way. I'm wary of adding new features (I consider integrating SPL to
be a new feature, for instance) which may upset the stability that
we've just recently achieved.
> There won't be truly drastic internals rewrites at this point, but we
> are not 100% feature complete. Things like a modified API for
> overloading, or clarifications in the type hint model are certainly
> valid for consideration in the beta process. There will of course be
> lots of bugfixing, but I don't think we should be overly strict at this
> point.
Not to be too picky (after all, I'm not directly involved in any of
this code at this point, so I don't have any real authority there),
but I'd really like to see a PHP project-wide release roadmap for PHP
5 than a bunch of developers posting their TODO lists. I realize
that's what you're trying to generate, but it seems like whatever
results will be largely emergent and de facto based on these TODO
lists, with very little strategy involved.
The fact that this discussion is even happening in the first place is
indicative of a lack of developer unity over the issue.
This is all just my opinion, of course.
--
Jon Parise (j...@php.net) :: The PHP Project (http://www.php.net/)
--
Derick Rethans
> At 08:31 30/06/2003, Derick Rethans wrote:
> >On Sun, 29 Jun 2003, Rasmus Lerdorf wrote:
> >
> > > feature-complete full-steam ahead for release. And that means bug fixes
> > > only from here on and it also means a PHP_5_0 branch.
>
> It doesn't mean that all of them will make it into PHP 5 [snip] It
> doesn't come to say that all of them will make it into PHP at all, by
> the way - some of them are open questions...
Right, that's what I meant... it was the "only bugfixes" I was referring
too.
Derick
--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
-------------------------------------------------------------------------
Derick Rethans http://derickrethans.nl/
International PHP Magazine http://php-mag.net/
-------------------------------------------------------------------------
Andi Gutmans
>Hello Andi,
>
>Monday, June 30, 2003, 8:10:30 AM, you wrote:
>
>AG> At 07:43 AM 30/6/2003 +0200, Andi Gutmans wrote:
> >>Hey,
> >>
> >>In my opinion beta 1 should be labeled as a beta. The fact that we are
definition
> >>of alpha is but in real life most beta's do end up having quite a few=
code
> >>changes before release.
> >>I agree that we should try and feature freeze as much as possible right
> >>now. I'd like to see PHP 5 out before the 6-9 month period Sterling
don't
> >>mess with the code too much and listen to the feedback of people who are
> >>starting to play around with it.
> >>
> >>In my opinion, half the stuff listed by Marcus should wait for PHP 5.1
> >>(which can be released very quickly after PHP 5):
> >>- Include SPL (forach/array hooking) (although we can discuss it and
> >>re-evaluate this once we finalize what we want).
>
considered
>AG> for PHP 5 I'll clarify what I meant. What I meant by re-evaluating is=
=20
>that
>AG> if everything falls in properly we should re-evaluate the patch before=
=20
>PHP 5.
>AG> Let's see another iteration of the spec with pretty names and then=
decide
>AG> :) Also, how are the benchmarks? What is slowed down and by how much?=
(it
>AG> might very well be worth it but I'd like to know more or less). Last=
but
>AG> not least, are there any things which won't work with this such as=20
>foreach
>AG> with references and other problems?
>
>According to foreach hooking
>a) I couldn't make out any problem that isn't fixed right now
>b) When included into the engine the differences are
> 3 additional comparisons in FE_RESET (2 pointers, 1 integer)
> 1 additional check in FE_FETCH (integer)
> 2 additional checks and a complex fetch in (SWITCH_FREE)
> -> that should be near to zero impact.
> In the early stages when it wasn't that optimized it was already near
> unmeasurable.
what
> i can do more. Of the new oo things it is right now one of the best
> documented and tested. So others have to test and report :-)
>
>Array hooking is somewhat different. The impact is higher and it isn't
here
>is whether we want it or not. But again being integrated in the engine the
>overhead can be reduced to a level described in foreach hooking.
Can you please post a patch for the foreach() stuff (i.e. collection and=20
iterator)?
I don't exactly remember what you mean by array hooking. Is that what=20
Andrei wants or does it also include a user-land interface to overload?
Andi
Marcus Börger
Monday, June 30, 2003, 5:58:42 PM, you wrote:
AG> At 08:54 AM 30/6/2003 +0200, Marcus Börger wrote:
>>Hello Andi,
>>
>>Monday, June 30, 2003, 8:10:30 AM, you wrote:
>>
>>AG> At 07:43 AM 30/6/2003 +0200, Andi Gutmans wrote:
>> >>Hey,
>> >>
>> >>In my opinion beta 1 should be labeled as a beta. The fact that we are
>> >>fixing a few features doesn't mean it's alpha. I know what the definition
>> >>of alpha is but in real life most beta's do end up having quite a few code
>> >>changes before release.
>> >>I agree that we should try and feature freeze as much as possible right
>> >>now. I'd like to see PHP 5 out before the 6-9 month period Sterling
>> >>mentioned. I think we can probably do it within about 4 months if we don't
>> >>mess with the code too much and listen to the feedback of people who are
>> >>starting to play around with it.
>> >>
>> >>In my opinion, half the stuff listed by Marcus should wait for PHP 5.1
>> >>(which can be released very quickly after PHP 5):
>> >>- Include SPL (forach/array hooking) (although we can discuss it and
>> >>re-evaluate this once we finalize what we want).
>>
>>AG> After Sterling reminded me that I did say that this should be considered
>>AG> for PHP 5 I'll clarify what I meant. What I meant by re-evaluating is
>>that
>>AG> if everything falls in properly we should re-evaluate the patch before
>>PHP 5.
>>AG> Let's see another iteration of the spec with pretty names and then decide
>>AG> :) Also, how are the benchmarks? What is slowed down and by how much? (it
>>AG> might very well be worth it but I'd like to know more or less). Last but
>>AG> not least, are there any things which won't work with this such as
>>foreach
>>AG> with references and other problems?
>>
>>According to foreach hooking
>>a) I couldn't make out any problem that isn't fixed right now
>>b) When included into the engine the differences are
>> 3 additional comparisons in FE_RESET (2 pointers, 1 integer)
>> 1 additional check in FE_FETCH (integer)
>> 2 additional checks and a complex fetch in (SWITCH_FREE)
>> -> that should be near to zero impact.
>> In the early stages when it wasn't that optimized it was already near
>> unmeasurable.
>>c) IT makes no sense letting me do more work in here. I really can't see what
>> i can do more. Of the new oo things it is right now one of the best
>> documented and tested. So others have to test and report :-)
>>
>>Array hooking is somewhat different. The impact is higher and it isn't
>>really optimized right now. That's why i made it optional. The question here
>>is whether we want it or not. But again being integrated in the engine the
>>overhead can be reduced to a level described in foreach hooking.
AG> Can you please post a patch for the foreach() stuff (i.e. collection and
AG> iterator)?
AG> I don't exactly remember what you mean by array hooking. Is that what
AG> Andrei wants or does it also include a user-land interface to overload?
Please look into spl. You can check it out spl (cvs co spl) into your
extension directory and recompile with --enable-spl --enable-spl-hook-all.
Then run the tests or play with the examples. Then you'll see. Documentation
and profiling results can be found in the readme files.
Best regards,
Marcus mailto:he...@php.net
Marcus Börger
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.
Andi Gutmans
>AG> Can you please post a patch for the foreach() stuff (i.e. collection=
and
>AG> iterator)?
>AG> I don't exactly remember what you mean by array hooking. Is that what
>AG> Andrei wants or does it also include a user-land interface to overload?
>
>Please look into spl. You can check it out spl (cvs co spl) into your
>extension directory and recompile with --enable-spl --enable-spl-hook-all.
>Then run the tests or play with the examples. Then you'll see.=
Documentation
>and profiling results can be found in the readme files.
I meant a patch for the Zend Engine. I can't really look over the code of=20
spl because it's not a diff against the current engine :)
Andi
Andi
Marcus Börger
Monday, June 30, 2003, 2:28:35 AM, you wrote:
MB> - Include SPL (forach/array hooking).
I tested the current patch:
http://marcus-boerger.de/php/ext/ze2/ze2-spl-20030701.diff.tgz
and profiled it again. What i did (in case someone doesn't know yet) was to
read 10 rows of three columns from a sqlite database 10 times. Further more
profiled a 'php -h' call and substracted that timing. So i only have the
looping and some very little overhead.
Using a normal for loop (minus php -h) is used for 100%.
Then i did the same with sqlite_array_query() and got 87%.
Then i did it with spl-forach hooking and got 57%.
Wow that's nearly 2 times faster...
--
Best regards,
Marcus mailto:he...@php.net
Marcus Börger
Monday, June 30, 2003, 2:28:35 AM, you wrote:
MB> - Fix static class members. If the are public they need to be accessible from
MB> outside the class. If they have an initial value this value should be used
MB> and the keyword var should be working as well.
MB> php -r 'class t { static public $p = "x";}; $t = new t; var_dump($t->p);'
MB> php -r 'class t { static var $p = "x";}; $t = new t; var_dump($t->p);'
MB> php -r 'class t { static public $p = "x";}; echo $t::p;'
MB> To make this clear: $t->p would add a dynamic propery to instance t while we
MB> want to access the static property p which can only be achieved by a
MB> different notation which should be <class>'::'<static_member>.
Aha, using <class>::$<member> works....