Taking advantage of php|tek bringing a lot of people together, we had a PHP developers
meeting over 2 days before the conference. Day 1 was dedicated to technical issues in PHP
5 and 6, and day 2 was spent discussing potential features, migration issues, current
roadblocks, etc.
People who were at the meeting:
Day 1
- Brian Shire
- Derick Rethans
- Dmitry Stogov
- Elizabeth Smith
- Ilia Alshanetsky
- Sara Golemon
- Scott MacVicar
- Stas Malyshev
- Tom Hanrahan (Microsoft)
- Wez Furlong
- me
Day 2 (Day 1 people) +
- Ben Ramsey
- Cal Evans
- Chris Jones
- Chris Shiflett
- Hank Jannsen (Microsoft)
- Andrew Kass (Microsoft)
- Sean Coates
The notes from the meeting are available on the wiki:
http://wiki.php.net/summits/pdmnotesmay09
I don't want people here to assume that these notes are "decisions" necessarily. They
reflect the consensus of the group that was at the meeting and we should still take up the
unresolved or arguable issues on this list. But hopefully we have a more structured and
outlined list of things that we can follow for PHP 5.4/6. There are a couple of items that
were unclear from the original notes — looking at you, Liz Smith :) - so, those of you who
remember the discussion, please fill them in.
-Andrei
Taking advantage of php|tek bringing a lot of people together, we had a PHP
developers meeting over 2 days before the conference. Day 1 was dedicated to
technical issues in PHP 5 and 6, and day 2 was spent discussing potential
features, migration issues, current roadblocks, etc.
I assume the names in parentheses are people who volunteered to do the
task, not whoever brought it up? (very ambitious crowd) :)
Regarding the stream interface, what does "FIIK" mean?
I would really love such an interface, the current situation is very
confusing, and I once upon a time had a rough draft of it..
And regarding reserving the "PHP" namespace, this was brought up
during the 5.3 release cycle and is something that imo should be done
in 5.3.. I'm unsure what happened to that discussion, probably
dissolved into separator war.
-Hannes
Hannes Magnusson wrote:
I assume the names in parentheses are people who volunteered to do the
task, not whoever brought it up? (very ambitious crowd) :)
Volunteered to do it or at least guide others.
Regarding the stream interface, what does "FIIK" mean?
I would really love such an interface, the current situation is very
confusing, and I once upon a time had a rough draft of it..
http://www.urbandictionary.com/define.php?term=FIIK
That was one that I couldn't decipher from Liz's notes.
And regarding reserving the "PHP" namespace, this was brought up
during the 5.3 release cycle and is something that imo should be done
in 5.3.. I'm unsure what happened to that discussion, probably
dissolved into separator war.
Quite likely.
-Andrei
Andrei Zmievski wrote:
Hannes Magnusson wrote:
I assume the names in parentheses are people who volunteered to do the
task, not whoever brought it up? (very ambitious crowd) :)Volunteered to do it or at least guide others.
Regarding the stream interface, what does "FIIK" mean?
I would really love such an interface, the current situation is very
confusing, and I once upon a time had a rough draft of it..
and you didn't ask either Andrei ;)
yes Hannes - interfaces for userland implemented streams would help
people trying to figure out if they have all the methods they need for a
particular stream type (SeekableStream et al) - this would be backward
compat (you wouldn't HAVE to implement the interfaces IIRC, at least not
right away) but would help things along - Sara had the general ideas for
how this would be done.
rough draft sounds good - code?
Thanks
Elizabeth Smith
Elizabeth M Smith wrote:
yes Hannes - interfaces for userland implemented streams would help
people trying to figure out if they have all the methods they need for a
particular stream type (SeekableStream et al) - this would be backward
compat (you wouldn't HAVE to implement the interfaces IIRC, at least not
right away) but would help things along - Sara had the general ideas for
how this would be done.rough draft sounds good - code?
Can you update the wiki with this? :)
-Andrei
-----Original Message-----
From: Elizabeth M Smith [mailto:auroraeosrose@gmail.com]
Sent: Wednesday, June 03, 2009 2:43 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Notes from the PDM in Chicago
yes Hannes - interfaces for userland implemented streams would help
people trying to figure out if they have all the methods they need for
a
particular stream type (SeekableStream et al) - this would be backward
compat (you wouldn't HAVE to implement the interfaces IIRC, at least
not
right away) but would help things along - Sara had the general ideas
for
how this would be done.
Btw, this is also true for PDO. We would want interfaces for PDOStatement and some other classes there too. That is in the TODO for PDO I believe but if we do this then let's make sure we do it consistently.
Andi
-----Original Message-----
From: Elizabeth M Smith [mailto:auroraeosrose@gmail.com]
Sent: Wednesday, June 03, 2009 2:43 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Notes from the PDM in Chicago
yes Hannes - interfaces for userland implemented streams would help
people trying to figure out if they have all the methods they need for
a
particular stream type (SeekableStream et al) - this would be backward
compat (you wouldn't HAVE to implement the interfaces IIRC, at least
not
right away) but would help things along - Sara had the general ideas
for
how this would be done.Btw, this is also true for PDO. We would want interfaces for PDOStatement and some other classes there too. That is in the TODO for PDO I believe but if we do this then let's make sure we do it consistently.
I would suggest to create a specific RFC about this topic in the wiki.
Cheers,
Pierre
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Wednesday, June 03, 2009 11:50 PM
To: Andi Gutmans
Cc: Elizabeth M Smith; internals@lists.php.net
Subject: Re: [PHP-DEV] Notes from the PDM in ChicagoBtw, this is also true for PDO. We would want interfaces for
PDOStatement and some other classes there too. That is in the TODO for
PDO I believe but if we do this then let's make sure we do it
consistently.I would suggest to create a specific RFC about this topic in the wiki.
The requirement itself is captured in http://wiki.php.net/rfc/pdov1. The
problem is of course coming up with an RFC for a standard way to do
interfaces for internal classes that need that (naming convention).
Will try and look into what precedence we have and see what we can
suggest.
Andi
Elizabeth M Smith wrote:
yes Hannes - interfaces for userland implemented streams would help
people trying to figure out if they have all the methods they need for a
particular stream type (SeekableStream et al) - this would be backward
compat (you wouldn't HAVE to implement the interfaces IIRC, at least not
right away) but would help things along - Sara had the general ideas for
how this would be done.rough draft sounds good - code?
Thanks
Elizabeth Smith
While dealing with the streams interfaces, what about making the api
saner, too?
All those bucket and brigade functions make streams unnecessarily complex
to deal with.
http://www.php.net/manual/en/ref.stream.php
While dealing with the streams interfaces, what about making the api
saner, too?
All those bucket and brigade functions make streams unnecessarily complex
to deal with.
http://www.php.net/manual/en/ref.stream.php
I made an honest attempt documenting the stream wrapper
(http://php.net/streamwrapper) few weeks ago and was planning on
hitting the filter stuff next.. I lost to many braincells in the
process and fear going through the filters will leave me with none
left..
Help appreciated! :)
-Hannes
Andrei Zmievski wrote:
Hannes Magnusson wrote:
I assume the names in parentheses are people who volunteered to do the
task, not whoever brought it up? (very ambitious crowd) :)Volunteered to do it or at least guide others.
I think some people were "volunteered" based on prior contributions?
The first I heard of my role in phar for PHP 6 was reading it on the
wiki. Not that I have a problem with that, but I wonder if there are
other people who don't know their names are on the list?
Thanks,
Greg
Greg Beaver wrote:
I think some people were "volunteered" based on prior contributions?
The first I heard of my role in phar for PHP 6 was reading it on the
wiki. Not that I have a problem with that, but I wonder if there are
other people who don't know their names are on the list?
Yes, we basically looked at the current maintainer of the extension or code when making
the list. Hopefully, this is not a problem with anyone - people can pass off the task to
someone else.
-Andrei
Taking advantage of php|tek bringing a lot of people together, we had a PHP
developers meeting over 2 days before the conference. Day 1 was dedicated to
technical issues in PHP 5 and 6, and day 2 was spent discussing potential
features, migration issues, current roadblocks, etc.People who were at the meeting:
Day 1
* Brian Shire
* Derick Rethans
* Dmitry Stogov
* Elizabeth Smith
* Ilia Alshanetsky
* Sara Golemon
* Scott MacVicar
* Stas Malyshev
* Tom Hanrahan (Microsoft)
* Wez Furlong
* meDay 2 (Day 1 people) +
* Ben Ramsey
* Cal Evans
* Chris Jones
* Chris Shiflett
* Hank Jannsen (Microsoft)
* Andrew Kass (Microsoft)
* Sean CoatesThe notes from the meeting are available on the wiki:
http://wiki.php.net/summits/pdmnotesmay09
I don't want people here to assume that these notes are "decisions"
necessarily.
You mean "are not decicions" right?
Cheers,
Pierre
I don't want people here to assume that these notes are "decisions"
necessarily. They reflect the consensus of the group that was at the
meeting and we should still take up the unresolved or arguable
issues on this list. But hopefully we have a more structured and
outlined list of things that we can follow for PHP 5.4/6. There are
a couple of items that were unclear from the original notes —
looking at you, Liz Smith :) - so, those of you who remember the
discussion, please fill them in.
To me its absolutely critical that we do not give the impression that
the next bigger update after 5.3 will be 5.4. The next big thing is
6.0. If we do a 5.4 then it will come after 6.0, just like 4.4 to ease
migration. But it makes no sense to release 5.4 with forward
compatibility stuff until we know we really nailed 6.0.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
2009/6/4 Lukas Kahwe Smith mls@pooteeweet.org:
I don't want people here to assume that these notes are "decisions"
necessarily. They reflect the consensus of the group that was at the meeting
and we should still take up the unresolved or arguable issues on this list.
But hopefully we have a more structured and outlined list of things that we
can follow for PHP 5.4/6. There are a couple of items that were unclear from
the original notes — looking at you, Liz Smith :) - so, those of you who
remember the discussion, please fill them in.To me its absolutely critical that we do not give the impression that the
next bigger update after 5.3 will be 5.4. The next big thing is 6.0. If we
do a 5.4 then it will come after 6.0, just like 4.4 to ease migration. But
it makes no sense to release 5.4 with forward compatibility stuff until we
know we really nailed 6.0.
I completely agree, we have already seen how much further 5.3's
release process was extended by constant new proposals and in the
middle namespaces, doing a 5.4 (before a 6.0.0 alpha/beta/rc) will
most likely crease development in HEAD (again, again) and extend the
development a year. 5.4 could be a considerable upgrade after the
6.0.0 release, 6.0.0 have already been delayed many years, I remember
in Paris 2005 someone said something about an expected 6.0.0 alpha or
similar within a half year.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org--
--
regrads,
Kalle Sommer Nielsen
kalle@php.net
Hi Lukas.
To me its absolutely critical that we do not give the impression that
the next bigger update after 5.3 will be 5.4. The next big thing is 6.0.
Thumbs up, and good luck with this ambitious plan! ;) We'd be happy to
switch to PHP 6...
Regards,
Karsten
Lukas Kahwe Smith wrote:
To me its absolutely critical that we do not give the impression that
the next bigger update after 5.3 will be 5.4. The next big thing is 6.0.
If we do a 5.4 then it will come after 6.0, just like 4.4 to ease
migration. But it makes no sense to release 5.4 with forward
compatibility stuff until we know we really nailed 6.0.
Yes, let me make this absolutely clear. All development effort regarding new features and
such should go into PHP 6. PHP 5.4 should happen after majority of work on PHP 6 is done.
-Andrei