On Mon, 2010-08-09 at 18:19 -0700, Kris Craig wrote:
Currently, I'm working on several parallel feature additions to the date
extension.
Can you please send some patches first? We like to see some work before
handing out accounts.
johannes
--
PHP Internals - PHP Runtime Development
On Tue, 2010-08-10 at 10:19 +0800, Adam Harvey wrote:
I could not disagree more. I think one of the key lessons we should
have learned out of the whole 6.0 saga was that release early,
release often is a good thing
I will no support the release of trunk overly actively as long as the
type
Am 10.08.2010 10:45, schrieb Johannes Schlüter:
So we'd always have three branches, while two only receive bug fixes,
plus one branch for the next milestone.
+1
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/
Sebastian Bergmann wrote:
So we'd always have three branches, while two only receive bug fixes,
plus one branch for the next milestone.
+1
And currently 5.2.x is still the preferred base as there is still a lot of third
party stuff that has to make the transition to 5.3.x ... Pushing new
2010/8/10 Johannes Schlüter johan...@php.net:
Yes. Release early, release often is a good thing. What I'd also like is
to have a Ubuntu-like support model. Where we have one LTS (long term
supported) version (now for instance 5.3) which will get bug fixes for
quite some time and an early
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/10/2010 11:25 AM, Adam Harvey wrote:
We might end up needing
to rethink how we structure the manual by looking at something like
the Python approach of having separate manuals for separate versions,
which would require a not-insignificant
hi,
On Tue, Aug 10, 2010 at 4:19 AM, Adam Harvey ahar...@php.net wrote:
On 10 August 2010 07:28, Pierre Joye pierre@gmail.com wrote:
On Mon, Aug 9, 2010 at 11:56 PM, Kalle Sommer Nielsen ka...@php.net wrote:
With the recent additions to 5.4, aren't we getting closer to have a
public alpha
On Tue, 2010-08-10 at 17:25 +0800, Adam Harvey wrote:
– The LTS branch is going to become more and more difficult to
backport fixes to as it diverges from the other two branches, and I
can see developers not bothering after a certain point, which may be
counter productive.
Except for things
On Tue, Aug 10, 2010 at 11:38, Matti Bickel m...@rateu.de wrote:
As an PHP developer: Providing manuals based on version sounds like a
good idea. But I'm not sure about the amount of additional work involved
and the willingness of docs contributors to do this..
Thats a heckofamore work then
2010/8/10 Johannes Schlüter johan...@php.net:
On Tue, 2010-08-10 at 17:25 +0800, Adam Harvey wrote:
– The LTS branch is going to become more and more difficult to
backport fixes to as it diverges from the other two branches, and I
can see developers not bothering after a certain point, which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/10/2010 11:47 AM, Hannes Magnusson wrote:
On Tue, Aug 10, 2010 at 11:38, Matti Bickel m...@rateu.de wrote:
As an PHP developer: Providing manuals based on version sounds like a
good idea. But I'm not sure about the amount of additional work
On Tue, 10 Aug 2010, Johannes Schlüter wrote:
So we'd always have three branches, while two only receive bug fixes,
plus one branch for the next milestone.
That's exactly what we have now: 5.2, 5.3 and trunk. I think your LTS
idea is way too optimistic. I really don't care about porting bug
On Mon, 9 Aug 2010, Kris Craig wrote:
Currently, I'm working on several parallel feature additions to the
date extension. Specifically with regard to accurate calculation of
seasonal equinox, an added paremeter character to display the current
season in the date() function, limited
On Mon, 9 Aug 2010, Kalle Sommer Nielsen wrote:
With the recent additions to 5.4, aren't we getting closer to have a
public alpha release, or just a development test as we have many great
additions and changes to the current trunk or atleast set up some sort
of roadmap for what we all like
2010/8/10 Derick Rethans der...@php.net:
That's exactly what we have now: 5.2, 5.3 and trunk. I think your LTS
idea is way too optimistic. I really don't care about porting bug fixes
back to 5.2 because it is *four* years old. PHP 5.3 has been out for a
year. Right now there are not many API
2010/8/10 Lukas Kahwe Smith m...@pooteeweet.org:
On 10.08.2010, at 10:45, Johannes Schlüter wrote:
On Tue, 2010-08-10 at 10:19 +0800, Adam Harvey wrote:
Yes. Release early, release often is a good thing. What I'd also like is
to have a Ubuntu-like support model. Where we have one LTS (long
On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote:
Is LTS really something we need to provide? Seems to me like this is
something the linux vendors take care of for the most part. Of course
this leaves windows, OSX (and maybe some others).
Well, I don't see it as
On 10.08.2010, at 10:45, Johannes Schlüter wrote:
On Tue, 2010-08-10 at 10:19 +0800, Adam Harvey wrote:
Yes. Release early, release often is a good thing. What I'd also like is
to have a Ubuntu-like support model. Where we have one LTS (long term
supported) version (now for instance 5.3)
2010/8/10 Johannes Schlüter johan...@schlueters.de
On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote:
Is LTS really something we need to provide? Seems to me like this is
something the linux vendors take care of for the most part. Of course
this leaves windows, OSX (and maybe some
On Tue, 10 Aug 2010, Johannes Schlüter wrote:
On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote:
Is LTS really something we need to provide? Seems to me like this is
something the linux vendors take care of for the most part. Of course
this leaves windows, OSX (and maybe some
Am 10.08.2010 17:14, schrieb Derick Rethans:
I think our current way work pretty well. There is 5.2 which is
security-fix supported, 5.3 that is supported and trunk/5.4 that's on
the way to alpha.
This only works if manage to keep the time between new code is
committed to trunk and new
I've been digging a little deeper and have figured out that I probably could
retrieve what I want (realpath of first executed file) from included_files
hash (first entry, obviously). Unfortunately, doing it like this (sampled
from get_included_files() implementation):
char *hentry;
On 10.08.2010, at 17:20, Sebastian Bergmann wrote:
Am 10.08.2010 17:14, schrieb Derick Rethans:
I think our current way work pretty well. There is 5.2 which is
security-fix supported, 5.3 that is supported and trunk/5.4 that's on
the way to alpha.
This only works if manage to keep the
On Tue, 10 Aug 2010, Sebastian Bergmann wrote:
Am 10.08.2010 17:14, schrieb Derick Rethans:
I think our current way work pretty well. There is 5.2 which is
security-fix supported, 5.3 that is supported and trunk/5.4 that's on
the way to alpha.
This only works if manage to keep the
Am 10.08.2010 17:25, schrieb Derick Rethans:
Yes, and that's why I want 5.4 alpha1 out soonish...
Exactly.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime
2010/8/10 Derick Rethans der...@php.net
On Tue, 10 Aug 2010, Johannes Schlüter wrote:
On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote:
Is LTS really something we need to provide? Seems to me like this is
something the linux vendors take care of for the most part. Of course
On Tue, 2010-08-10 at 16:14 +0100, Derick Rethans wrote:
On Tue, 10 Aug 2010, Johannes Schlüter wrote:
On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote:
Is LTS really something we need to provide? Seems to me like this is
something the linux vendors take care of for the most
Hi,
On Tue, 2010-08-10 at 17:24 +0200, Bostjan Skufca wrote:
I've been digging a little deeper and have figured out that I probably
could retrieve what I want (realpath of first executed file) from
included_files hash (first entry, obviously). Unfortunately, doing it
like this (sampled from
2010/8/10 Johannes Schlüter johan...@schlueters.de
Hi,
On Tue, 2010-08-10 at 17:24 +0200, Bostjan Skufca wrote:
I've been digging a little deeper and have figured out that I probably
could retrieve what I want (realpath of first executed file) from
included_files hash (first entry,
On Tue, Aug 10 2010, Derick Rethans wrote
On Mon, 9 Aug 2010, Kalle Sommer Nielsen wrote:
With the recent additions to 5.4, aren't we getting closer to have a
public alpha release, or just a development test as we have many
great
additions and changes to the current trunk or atleast
Of course! Here's a patch of php_date.c (currently based off 5.3.2; I'll
need to rebase off 5.3.3 of course) showing the seasonal equinox support
I've added thus far. The formulas in there took quite a bit of research to
find, but ultimately I was able to find them in an old book titled,
Sorry, I guess it would help if I actually attached the patch. Here it
is.
--Kris
2010/8/10 Kris Craig kris.cr...@gmail.com
Of course! Here's a patch of php_date.c (currently based off 5.3.2; I'll
need to rebase off 5.3.3 of course) showing the seasonal equinox support
I've added
On 10/08/10 20:28, Kris Craig wrote:
Sorry, I guess it would help if I actually attached the patch. Here
it is.
The list strips attachments with filenames ending in something other
than .txt - resend or perhaps put it online somewhere?
--
Cheers,
Michael
--
PHP Internals - PHP Runtime
Hi,
is there any reason why no namespace separator constant exists in PHP. I
have many cases where I concatenate strings to a namespace. This ends up
with many class constants like const NS_SEPARATOR = '\\'. A default PHP
constant would be a better way to handle such cases.
Greetings,
Christian
On Tue, Aug 10, 2010 at 21:56, Christian Kaps christian.k...@mohiva.com wrote:
Hi,
is there any reason why no namespace separator constant exists in PHP. I
have many cases where I concatenate strings to a namespace. This ends up
with many class constants like const NS_SEPARATOR = '\\'. A
On Tue, Aug 10, 2010 at 9:59 PM, Daniel Egeberg daniel.egeb...@gmail.comwrote:
On Tue, Aug 10, 2010 at 21:56, Christian Kaps christian.k...@mohiva.com
wrote:
Hi,
is there any reason why no namespace separator constant exists in PHP. I
have many cases where I concatenate strings to a
On 8/10/10 3:03 PM, Ferenc Kovacs wrote:
like DIRECTORY_SEPARATOR I guess
Tyrael
but, DIRECTORY_SEPARATOR is system dependent. The namespace separator is
not. It is is always \.
--
Brian.
http://brian.moonspot.net/
--
PHP Internals - PHP Runtime Development Mailing List
To
Am 10.08.2010 22:07, schrieb Brian Moon:
On 8/10/10 3:03 PM, Ferenc Kovacs wrote:
like DIRECTORY_SEPARATOR I guess
Tyrael
but, DIRECTORY_SEPARATOR is system dependent. The namespace separator
is not. It is is always \.
OK. This is clear.
--
PHP Internals - PHP Runtime Development
Woops, sorry. Here's the file renamed to .txt. Thanks for the tip!
--Kris
On Tue, Aug 10, 2010 at 12:50 PM, Michael Maclean m...@php.net wrote:
On 10/08/10 20:28, Kris Craig wrote:
Sorry, I guess it would help if I actually attached the patch. Here
it is.
The list strips
Hello Christian
2010/8/10 Christian Kaps christian.k...@mohiva.com:
Hi,
is there any reason why no namespace separator constant exists in PHP. I
have many cases where I concatenate strings to a namespace. This ends up
with many class constants like const NS_SEPARATOR = '\\'. A default PHP
Greetings hackers
I spoke with Derick today, and we both agreed on releasing an alpha of
PHP 5.4 to show the public what we have been working since 5.3. We are
going to release an alpha at september 2nd, which meaning packaging is
going to happen on 1st September (SVN tag, Windows binaries, etc.)
On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
type hinting
For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Total thumbs up on that.
http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html
just tells it all. A total epic fail.
2010/8/11 Johannes Schlüter johan...@schlueters.de:
On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
type hinting
For the record: I consider
2010/8/11 Johannes Schlüterjohan...@schlueters.de:
On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
type hinting
For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.
Is there a summary of what we ended up with? I got so
On Wed, 11 Aug 2010, Johannes Schlüter wrote:
On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
type hinting
For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.
I will try to sum up my view point once more:
1. right
On 8/10/10 3:30 PM, Brian Moon wrote:
2010/8/11 Johannes Schlüterjohan...@schlueters.de:
On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
type hinting
For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.
Is there a
Hi!
With Traits, interned strings/hash table optimizations, array deref.,
type hinting, and more we both (me and Derick) belive we are ready for
Please do not call strict typing type hinting.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
1. right now we *have* strict type checks for classes and arrays in the
form of classname or array
Because classes and arrays were never intechangeable types and there was
never implicit or explicit conversion between SplRecursiveTreeIterator
and Zend_Pdf_Generator - it doesn't even
Hi!
For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.
I agree completely. The fact that obvious absence of consensus is
ignored and we are releasing feature that clearly has no consensus
behind it as a part of an official release -
On Aug 10, 2010, at 3:11 PM, Johannes Schlüter wrote:
On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
type hinting
For the record: I consider the current implementation as (one of) the
biggest mistakes in the last ten years.
johannes
I'm happy to see a more strict
Well, the thing is objects and arrays are complex types, so you can't
pass anything exept array to an array type hint, it just dosen't make
sence. Not everything can be converted to array and vice-versa. Same
with objects - every object is it's own type.
But the primitive types behave
They aren't hints. It is strict typing and in its current form I would
ask you guys not to call the 5.4 release PHP. Because it won't be.
Fully agreed.
I'd suggest NoPHP. AntiPHP might also work.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To
Having two similar syntaxes that work differently - would make the
situation even worse that it is now - I beleive. And I totally agree
with Rasmus - strict typed language mustnt be called PHP. (Just a poor
user's notice to all of you internals' geeks out there)
2010/8/11 Stas Malyshev
Derick's point was about consistency. The approach described in his
mail is consistent with current syntax and mechanism(s). Current
typehints do not apply any kind of conversion, so treating scalar
hints the same way is consistent with the current mechanism.
Reusing the typecasting syntax for
Hi!
Derick's point was about consistency. The approach described in his
mail is consistent with current syntax and mechanism(s). Current
No it is not. There's no functions that produce errors when fed 1
instead of boolean true - all internal functions convert.
typehints do not apply any
hi,
Announcing what?
I do not know where and when you talked to Derick but seriously, it
does not matter. At all.
For one, there is no release decision yet. No need to say that there
is no RM either. Not you, and certainly not Derick (no offense meant,
but what is happening right now is the
Yes, I understand the point of his post. But as you know - the perfect
world and the real world rearly meat together.
Just read the prevoius themes - majority was on the typecasting hints
for the primitive types. We even layed the rules quite in detail.
The thing is it will be pain in the ass to
On 11 August 2010 01:50, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Derick's point was about consistency. The approach described in his
mail is consistent with current syntax and mechanism(s). Current
No it is not. There's no functions that produce errors when fed 1 instead of
boolean
On 11 August 2010 02:13, Arvids Godjuks arvids.godj...@gmail.com wrote:
Remember the main PHP principle? KISS. So keep it, blody hell, simple!
Please try to realize that what you find simple may not appear as
simple to everybody else. To me, typechecking is very simple: if type
equals typehint
Hi!
First of all, I am talking about the typehinting syntax and mechanism
here. As Derick pointed out, current typehints are strict.
Talking about strict vs. non-strict for class types is meaningless.
You can consider them non-strict if you want - they convert if the
conversion is
Hi!
Might be the time to rename what we currently call type hinting then.
Because what we currently have is strict typing as well.
Maybe. The term hint was inexact from the start, as hint means
(Collins English Dictionary):
1. a suggestion or implication given in an indirect or subtle
Sounds like a reasonable name change. PHP never really had
type-hinting since even array or Object type hints would throw out
any value that didn't precisely match the requested type by the
method/function declaration.
On Tue, Aug 10, 2010 at 8:53 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Sascha,
Does this mean @group authorizes use of NoPHP as a name for a
derivative PHP version (gotta ask according to the license) ? ;-)
On Tue, Aug 10, 2010 at 7:04 PM, Sascha Schumann sas...@schumann.net wrote:
They aren't hints. It is strict typing and in its current form I would
ask you
On Tue, Aug 10, 2010 at 5:20 PM, Sebastian Bergmann sebast...@php.net wrote:
Am 10.08.2010 17:14, schrieb Derick Rethans:
I think our current way work pretty well. There is 5.2 which is
security-fix supported, 5.3 that is supported and trunk/5.4 that's on
the way to alpha.
This only works
On Tue, Aug 10, 2010 at 5:25 PM, Derick Rethans der...@php.net wrote:
Yes, and that's why I want 5.4 alpha1 out soonish...
s,want,would like to,
Even if you were the RM, that's not your call. Tired of seeing doing
the same thing again and again.
Cheers,
--
Pierre
@pierrejoye |
On 11 August 2010 02:50, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
First of all, I am talking about the typehinting syntax and mechanism
here. As Derick pointed out, current typehints are strict.
Talking about strict vs. non-strict for class types is meaningless.
By strict typehints I
On 10-08-11 12:03 AM, Josh Davis wrote:
On 11 August 2010 02:50, Stas Malyshevsmalys...@sugarcrm.com wrote:
Hi!
First of all, I am talking about the typehinting syntax and mechanism
here. As Derick pointed out, current typehints are strict.
Talking about strict vs. non-strict for class
On 08/11/2010 12:03 AM, Kalle Sommer Nielsen wrote:
Greetings hackers
I spoke with Derick today, and we both agreed on releasing an alpha of
PHP 5.4 to show the public what we have been working since 5.3. We are
going to release an alpha at september 2nd, which meaning packaging is
going to
On Aug 10, 2010, at 10:42 PM, Michael Wallner wrote:
On 08/11/2010 12:03 AM, Kalle Sommer Nielsen wrote:
Greetings hackers
I spoke with Derick today, and we both agreed on releasing an alpha of
PHP 5.4 to show the public what we have been working since 5.3. We are
going to release an
69 matches
Mail list logo
