Notes from the PDM in Chicago

16 years ago by Andrei Zmievski — view source

unread

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

16 years ago by Hannes Magnusson — view source

unread

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

16 years ago by Andrei Zmievski — view source

unread

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

16 years ago by Elizabeth M Smith — view source

unread

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

16 years ago by Andrei Zmievski — view source

unread

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

16 years ago by Andi Gutmans — view source

unread

-----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

16 years ago by Pierre Joye — view source

unread

-----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

http://blog.thepimp.net | http://www.libgd.org

16 years ago by Andi Gutmans — view source

unread

-----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 Chicago

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.

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

16 years ago by Keisial — view source

unread

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

16 years ago by Hannes Magnusson — view source

unread

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

16 years ago by Greg Beaver — view source

unread

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

16 years ago by Andrei Zmievski — view source

unread

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

16 years ago by Pierre Joye — view source

unread

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.

You mean "are not decicions" right?

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

16 years ago by Lukas Kahwe Smith — view source

unread

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

16 years ago by Kalle Sommer Nielsen — view source

unread

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

16 years ago by Karsten Dambekalns — view source

unread

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

16 years ago by Andrei Zmievski — view source

unread

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