On Mon, Mar 30, 2015 at 8:50 PM, Stanislav Malyshev wrote:
> Hi!
>
>> I tend to agree that it would be easier for all parties if we stop
>> adding stuff in micro versions, as it is easier to remember and
>
> I don't think it is a good idea. Imagine you are a PHP developer working
> on a pr
Hi!
> Have you considered developers targeting shared hosting? Working on an
> improvement they have to wait for five years to use it is most certainly
> annoying. However, introducing this feature in a revision might not
> really help them at all.
Not immediately, but shared hoster much faster
> -Ursprüngliche Nachricht-
> Von: Lazare Inepologlou [mailto:linep...@gmail.com]
> Gesendet: Dienstag, 31. März 2015 00:01
> An: Christoph Becker
> Cc: Zeev Suraski; PHP internals
> Betreff: Re: [PHP-DEV] Re: Naming of 'weak' type hints
>
> Zeev Suraski wrote:
>
> > One thing that I thin
Stanislav Malyshev wrote:
>> I can certainly see value in a special case for including things in both
>> 5.6 and 7.x, both before and after 7.0 is released, but the the case for
>> backporting anything other than a genuine bug fix to 5.5.x right now
>> seems fairly weak, as will the case for backp
Hi!
> even agreeing upon something like adding features in a micro version
> needs a format RFC and a 2/3 vote would allow us to have a conservative
> default while we could still make exceptions with a clear process to follow.
I'm still not sure which problem we're trying to solve. Can someone g
Hi!
> If an organisation has standardised on an old version of PHP, there's a
By "old" you're meaning current stable, I presume.
> fair chance that the builds they are using are not from php.net, but
> from their OS distribution. As has been mentioned here before, these
There are no builds on p
Zeev Suraski wrote:
> One thing that I think we should change is how we refer to the ‘weak’ type
> hints. The word ‘weak’ has a negative ring to it, and considering this is
> how the language behaves across the board it’s a pretty bad name for this
> feature.
Borrowing from C#, I would suggest t
On Mon, Mar 30, 2015 at 10:52 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > I know that our official release process allows that, but there are some
> > reasonable arguments against doing that and this topic was brought up
> > multiple times related to specific fixes.
>
> Adding an option I think it'
Hi!
> I know that our official release process allows that, but there are some
> reasonable arguments against doing that and this topic was brought up
> multiple times related to specific fixes.
Adding an option I think it's ok provided it's not controversial and not
an attempt to create entirely
On 30/03/2015 19:50, Stanislav Malyshev wrote:
Hi!
I tend to agree that it would be easier for all parties if we stop
adding stuff in micro versions, as it is easier to remember and
I don't think it is a good idea. Imagine you are a PHP developer working
on a project, and you noticed
Hi!
> I tend to agree that it would be easier for all parties if we stop
> adding stuff in micro versions, as it is easier to remember and
I don't think it is a good idea. Imagine you are a PHP developer working
on a project, and you noticed there's some small functionality missing
that w
Am 30.03.2015 um 12:58 schrieb Thomas Punt:
Hey,
Imho TypeException may not be best name for
it, as it's also thrown for non-type related error conditions, like
mismatched argument count.
Would SignatureException be a more apt name for these error conditions?
We already have an InvalidArgume
Hi!
> One thing that I think we should change is how we refer to the ‘weak’ type
> hints. The word ‘weak’ has a negative ring to it, and considering this is
I would really prefer we stop calling it "hints". It is misleading as it
is implying this is something which can be easily ignored if wishe
Zeev Suraski wrote:
> One thing that I think we should change is how we refer to the ‘weak’ type
> hints. The word ‘weak’ has a negative ring to it, and considering this is
> how the language behaves across the board it’s a pretty bad name for this
> feature.
> Personally I think we should go fo
On Mon, Mar 30, 2015 at 4:04 AM, Ferenc Kovacs wrote:
> Hi,
>
> I know that our official release process allows that, but there are some
> reasonable arguments against doing that and this topic was brought up
> multiple times related to specific fixes.
> I have two open PRs like that:
> https://gi
Hi Dan,
The updated patch is at https://github.com/php/php-src/pull/1205
The main difference is in ext/intl.
If you don't see any problems I can commit it.
I didn't think about the classes you missed.
Thanks. Dmitry.
On Fri, Mar 27, 2015 at 7:32 PM, Dan Ackroyd wrote:
> On 26 March 2015 at 2
On Mar 30, 2015 5:29 PM, "Nikita Popov" wrote:
> From this thread, I'd say we have a consensus to deprecate it. From the
> Japanese side, both Yasuo and Masaki agree that this should be dropped and
> Masaki also linked a bug report where it is stated that the original
author
> of this functionali
On 30 March 2015 at 15:16, Zeev Suraski wrote:
> All,
>
>
>
> One thing that I think we should change is how we refer to the ‘weak’ type
> hints. The word ‘weak’ has a negative ring to it, and considering this is
> how the language behaves across the board it’s a pretty bad name for this
> featu
Hi Zeev,
Le 30 mars 2015 16:17, "Zeev Suraski" a écrit :
>
> All,
>
>
>
> One thing that I think we should change is how we refer to the ‘weak’ type
> hints. The word ‘weak’ has a negative ring to it, and considering this is
> how the language behaves across the board it’s a pretty bad name for
>
> We could
> also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’,
> although I think we can easily do without introducing a new word into the
> vocabulary here.
>
>From an user perspective, I'd suggest that "lax" would potentially carry
more negative connotations than "weak."
All,
One thing that I think we should change is how we refer to the ‘weak’ type
hints. The word ‘weak’ has a negative ring to it, and considering this is
how the language behaves across the board it’s a pretty bad name for this
feature.
Personally I think we should go for ‘dynamic’ when we d
On Mon, Mar 30, 2015 at 3:10 PM, Ferenc Kovacs wrote:
>
>
> On Mon, Mar 30, 2015 at 1:15 PM, Michael Wallner wrote:
>
>> On 30/03/15 12:04, Ferenc Kovacs wrote:
>> > Hi,
>> >
>> > I know that our official release process allows that, but there are some
>> > reasonable arguments against doing tha
On Mon, Mar 30, 2015 at 1:15 PM, Michael Wallner wrote:
> On 30/03/15 12:04, Ferenc Kovacs wrote:
> > Hi,
> >
> > I know that our official release process allows that, but there are some
> > reasonable arguments against doing that and this topic was brought up
> > multiple times related to specif
This RFC has been declined with 21 "Yes" votes and 26 "No" votes.
Regards, Niklas
2015-03-29 11:19 GMT+02:00 Pascal Martin, AFUP :
> Le 15/03/2015 20:31, Niklas Keller a écrit :
>
>> I just opened the vote for the in operator
>>
> Hi,
>
> Discussing this RFC with other people at AFUP, it seems t
Voting concluded yesterday on the Generator Delegation RFC; the proposal
passed 25-0 for inclusion in PHP7.
https://wiki.php.net/rfc/generator-delegation#vote
Thanks to everyone who read the proposal and contributed either directly or
indirectly.
-Daniel
On Mar 30, 2015 6:15 PM, "Michael Wallner" wrote:
>
> On 30/03/15 12:04, Ferenc Kovacs wrote:
> > Hi,
> >
> > I know that our official release process allows that, but there are some
> > reasonable arguments against doing that and this topic was brought up
> > multiple times related to specific fi
On 30/03/15 12:04, Ferenc Kovacs wrote:
> Hi,
>
> I know that our official release process allows that, but there are some
> reasonable arguments against doing that and this topic was brought up
> multiple times related to specific fixes.
> I have two open PRs like that:
> https://github.com/php/p
Hey,
> Imho TypeException may not be best name for
> it, as it's also thrown for non-type related error conditions, like
> mismatched argument count.
Would SignatureException be a more apt name for these error conditions?
-Tom
--
PHP Internals - PHP Runtime
On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev
wrote:
> Hi!
>
> I was never happy about this particular hack but that said, unless we
> *know* it is not used widely (and I suspect it is in Japan etc. where we
> don't have a lot of visibility due to language barrier) we can't really
> remove
Hi internals!
There are a number of open issues with regard to the exception hierarchy
for recently introduced exception, for which I would like to open a new
thread:
* Naming and classiness of BaseException. There's an RFC to change this to
a Throwable interface: https://wiki.php.net/rfc/throwa
Hi,
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to specific fixes.
I have two open PRs like that:
https://github.com/php/php-src/pull/1204
https://github.com/php/php-src/pull/9
On Mon, Mar 30, 2015 at 8:24 AM, Danylo Medinsky
wrote:
> Recently, as part of school course on optimization, I have identified a
> potential optimization or feature for PHP. After looking through the
> array.c file(located in etc/standard in the PHP source code), I noticed
> that both the in_arr
On Mon, Mar 30, 2015 at 9:04 AM, Yasuo Ohgaki wrote:
> Hi Pierre,
>
> On Mon, Mar 30, 2015 at 11:42 AM, Pierre Joye
> wrote:
>
>> On Mon, Mar 30, 2015 at 9:14 AM, Yasuo Ohgaki wrote:
>> > Hi Pierre,
>> >
>> > On Mon, Mar 30, 2015 at 10:54 AM, Pierre Joye
>> wrote:
>> >>
>> >> Same effects but
Hi Yasuo
On Mon, Mar 30, 2015 at 1:07 AM, Yasuo Ohgaki wrote:
>
> "int" should be fixed also.
> http://3v4l.org/95dHM
>
>
We have already fix for this: JSON_BIGINT_AS_STRING ( http://3v4l.org/vYXUk
)
> So option may be JSON_SCALAR_AS_STRING or
> additional JSON_INT_AS_STRING.
>
>
I was actually
Hi Pierre,
On Mon, Mar 30, 2015 at 11:42 AM, Pierre Joye wrote:
> On Mon, Mar 30, 2015 at 9:14 AM, Yasuo Ohgaki wrote:
> > Hi Pierre,
> >
> > On Mon, Mar 30, 2015 at 10:54 AM, Pierre Joye
> wrote:
> >>
> >> Same effects but totally unrelated topics. All functions dealing with
> >> large extern
35 matches
Mail list logo
