Hi!
On one side there's a clear BC break which, according to the related
RFC, is to be considered as a blocker, on the other one, a strong and
valid argument regarding spreading additional server variables.
I'm not sure being late in the release process is truely a valid
argument for accepting a
Being inside all the news yet to come in future versions of PHP, and also
participate in polls.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
Hi:
I have reset the vote, only vote for trunk now.
https://wiki.php.net/rfc/constdereference
What happens in your patch if something like ['foo', 'bar'][1] is used
in write context?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext
On Mon, 26 Dec 2011, Patrick ALLAERT wrote:
> 2011/12/24 Pierre Joye :
> >
> > Right but there is a clear BC break here. And yes I really don't like
> > how datetime deals with that but it is how it is, and it is certainly
> > the only case where it fails (or almost).
> >
> > On Sat, Dec 24, 2011
2011/12/27 Ilia Alshanetsky :
> I think the REQUEST_TIME semantics of returning float should remain as is.
>
> -1 for adding further environment variables.
As mentioned earlier, I don't like this option very much but at least
it solves the BC problem.
Do you have any other proposal to share?
Oppo
On Tue, Dec 27, 2011 at 2:42 PM, Dmitri Snytkine <
dsnytk...@ultralogistics.com> wrote:
> Odd how substring can be used as index of string.
oh, I see where the confusion comes from.
the reason why "foobar"["foo"] returns 'f' isn't that "foo" is a substring
of "foobar", but that "foo" will be cas
2011/12/27 Pierre Joye :
> On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans wrote:
>
>> Ah, that one. I got lost between all the commas and thought he meant an
>> RFC for changing REQUEST_TIME from int to float :-)
>
> :)
>
> Which name should we use?
>
> a) REQUEST_TIME_FLOAT
> b) REQUEST_TIME_MSE
On Sun, 25 Dec 2011, Stas Malyshev wrote:
> I see that test for bug 52062 (marked as fixed by this commit:
> http://svn.php.net/viewvc/?view=revision&revision=320481) now fails on my
> 32-bit system. Looking at the patch and the test, it can not actually succeed,
> as the test expects this:
> int(
Ilia Alshanetsky wrote:
I think the REQUEST_TIME semantics of returning float should remain as is.
-1 for adding further environment variables.
A proper explanation of why you take that attitude would be helpful. Personally
I expect REQUEST_TIME to be in the same resolution as the http format
On Tue, Dec 27, 2011 at 4:38 PM, Stas Malyshev wrote:
> Hi!
>
>
>> Hi:
>> I have reset the vote, only vote for trunk now.
>>
>> https://wiki.php.net/rfc/constdereference
>>
>
> What happens in your patch if something like ['foo', 'bar'][1] is used in
> write context?
>
this patch will not al
On Tue, Dec 27, 2011 at 2:15 PM, Dmitri Snytkine <
dsnytk...@ultralogistics.com> wrote:
> No sure who can and cannot vote, I don't see any way for me to vote.
>
https://wiki.php.net/rfc/voting
currently the following two groups can vote:
- people having php.net svn account
- people having a wiki
Scalars will not be supported as type hints. There was talk of a "scalar"
token added for validation in that category, but it does NOT need to be
supported for return type hinting to be included. Return type hints are
following the same logic as parameter type hints and should be considered in
Also, the RFC will be changing tonight/tomorrow'ish to take procedures
(functions) into account as well. I know there are many who want to address
the additional "types" to hint (e.g. scalar keyword), but I would like to focus
discussion of the RFC to its current state - which is to match the s
The change is inside 5.4 version which adjust breaks BC.
---
Ilia
On Dec 27, 2011 10:15 AM, "Patrick ALLAERT" wrote:
> 2011/12/27 Ilia Alshanetsky :
> > I think the REQUEST_TIME semantics of returning float should remain as
> is.
> >
> > -1 for adding further environment variables.
>
> As mentio
I'm sorry but even though I liked that RFC, I'd like to ask about type
hinting through annotations. Has anyone considered that? I think that it
would be nice because it also docs the functions at the same time.
To be honest I don't know even if that's possible. So, it's just a thought.
2011/12/24
No sure who can and cannot vote, I don't see any way for me to vote.
My opinion that it’s a good idea to have array and string dereference.
One feature however, looks odd, like it does not belong here:
echo "foobar"["foo"][0] // output f
Does it look odd to anyone else? I mean, this sort of thin
On Tue, 27 Dec 2011, Pierre Joye wrote:
> On Tue, Dec 27, 2011 at 11:37 AM, Derick Rethans wrote:
> > On Mon, 26 Dec 2011, Patrick ALLAERT wrote:
> >
> >> 2011/12/24 Pierre Joye :
> >> >
> >> > Right but there is a clear BC break here. And yes I really don't like
> >> > how datetime deals with th
Odd how substring can be used as index of string.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
"A Top 100 Logistics I.T. Provider in 2011"
-Original Message-
From: F
Am 27.12.2011 14:53, schrieb Hannes Magnusson:
> bjoriTue, 27 Dec 2011 13:53:11 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=321435
>
> Log:
> Looks like we need to explicity add libstdc++ on recent linux' too, like
> fedora 14 and ubun
I think the REQUEST_TIME semantics of returning float should remain as is.
-1 for adding further environment variables.
On Tue, Dec 27, 2011 at 7:52 AM, Derick Rethans wrote:
> On Tue, 27 Dec 2011, Pierre Joye wrote:
>
>> On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans wrote:
>>
>> > Ah, that o
I think annotations is a completely different topic to be discussed
separately. First the type hinting for variables and return values has to be
supported by the language, including hinting for primitive types. If and
when this is done, then, if annotations are supported natively, maybe these
2 can
Am 27.12.2011 16:36, schrieb Sebastian Bergmann:
> And PHP_5_3 does not need this?
I am asking because I cannot build PHP_5_3 with ext/intl on Fedora 16.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://t
On Tue, 27 Dec 2011, Pierre Joye wrote:
> On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans wrote:
>
> > Ah, that one. I got lost between all the commas and thought he meant an
> > RFC for changing REQUEST_TIME from int to float :-)
>
> Which name should we use?
>
> a) REQUEST_TIME_FLOAT
> b) RE
On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans wrote:
> Ah, that one. I got lost between all the commas and thought he meant an
> RFC for changing REQUEST_TIME from int to float :-)
:)
Which name should we use?
a) REQUEST_TIME_FLOAT
b) REQUEST_TIME_MSEC
c) other?
Cheers,
--
Pierre
@pierrej
hi Derick,
On Tue, Dec 27, 2011 at 11:37 AM, Derick Rethans wrote:
> On Mon, 26 Dec 2011, Patrick ALLAERT wrote:
>
>> 2011/12/24 Pierre Joye :
>> >
>> > Right but there is a clear BC break here. And yes I really don't like
>> > how datetime deals with that but it is how it is, and it is certainly
On Mon, 26 Dec 2011, Antony Dovgal wrote:
> On 12/26/2011 12:40 PM, Derick Rethans wrote:
>
> > I'll have a look when I get back home. Is there anything else you
> > want me to look at?
>
> Yes!
> https://bugs.php.net/bug.php?id=53437 =)
I've just had a look at the patch, and it seems to encode
2011/12/27 Ilia Alshanetsky :
> The change is inside 5.4 version which adjust breaks BC.
I don't follow you here Ilia.
As per https://wiki.php.net/rfc/releaseprocess:
* "Backward compatibility must be respected with the same major
releases, for example from 5.2 to 5.6."
* Going from x.y.z to x.y+
Hi
On Tue, 27 Dec 2011 13:26:59 +0100, Derick Rethans wrote:
On Mon, 26 Dec 2011, Antony Dovgal wrote:
On 12/26/2011 12:40 PM, Derick Rethans wrote:
> I'll have a look when I get back home. Is there anything else you
> want me to look at?
Yes!
https://bugs.php.net/bug.php?id=53437 =)
I'v
On Sat, Dec 24, 2011 at 7:07 AM, Pierre Joye wrote:
> Right, and that's why I would be in favour of a BC change, maybe by
> introducing a REQUEST_TIME_FLOAT instead, so people willing to use the
> float version can still have it while the existing code needs no
> change.
We spotted the same exact
On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT wrote:
> 2011/12/27 Ilia Alshanetsky :
> > The change is inside 5.4 version which adjust breaks BC.
>
> I don't follow you here Ilia.
>
> As per https://wiki.php.net/rfc/releaseprocess:
> * "Backward compatibility must be respected with the same maj
On Tue, Dec 27, 2011 at 16:48, Sebastian Bergmann wrote:
> Am 27.12.2011 16:36, schrieb Sebastian Bergmann:
>> And PHP_5_3 does not need this?
>
> I am asking because I cannot build PHP_5_3 with ext/intl on Fedora 16.
Hmh. Do they not ship with PHP5.3?
I would have expect them to submit a build
Hi!
3. $d->setTimestamp(1000) is not ever going to work as
zend_parse_parameters simply gives me long: 1215752192. This I find
really strange actually. Any clue?
That's probably float to long conversion, since 1000 is float on
32-bit.
--
Stanislav Malyshev, Software
32 matches
Mail list logo
