2015.03.16. 4:18 ezt írta ("Philip Sturgeon" ):
>
> One rule I liked when I was part of the FIG was that people can only
> vote on votes initiated after they became a member. That stops people
> signing up simply to vote on an RFC which needs more votes either way.
>
> I'm not saying that happened,
Am 16.03.2015 um 07:41 schrieb Xinchen Hui:
> what is the link problems?
http://pastebin.com/Tk1kaipQ
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Le 09/03/2015 17:50, Daniel Lowrey a écrit :
I'd like to announce voting for the Generator Return Expressions RFC:
https://wiki.php.net/rfc/generator-return-expressions#vote
Hi,
After discussing this RFC with other people at AFUP, it seems we (even
if not many of us did express themselves o
Hi Dennis,
On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz
wrote:
> Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:
> > Caller _must_ satisfy callee requirements. This is simple principle to
> > write a secure code.
> >
> > With this RFC, caller overrides security related setting. This means
> > s
On 16/03/15 00:16, Marco Pivetta wrote:
> Syntactic sugar won't really make things easier when adopting the language,
> and I don't like this sort of additional cognitive load either.
>
> In short, I stand firm on my "if you can implement it in userland, don't
> implement it in the language" idea.
On Mar 16, 2015 6:46 PM, "Yasuo Ohgaki" wrote:
>
> Hi Dennis,
>
> On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz
> wrote:
>
> > Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:
> > > Caller _must_ satisfy callee requirements. This is simple principle to
> > > write a secure code.
> > >
> > > With t
On 16/03/15 06:22, Xinchen Hui wrote:
>> It's in the RFC: "Whether or not the function being called was
>> > declared in a file that uses strict or weak type checking is
>> > irrelevant. The type checking mode depends on the file where the
>> > function is called."
> my fault, I must oversight of r
Hi,
On 16/03/2015 00:25, Leigh wrote:
Indeed we would, it's the kind of issue that would get solved pretty
quickly (imho). Maybe it was an issue at some point in the past and
there's still misinformation out there? Who knows, it certainly isn't an
issue today.
thanks everyone for the clarifi
On 16/03/15 03:29, Yasuo Ohgaki wrote:
>
> I agree partly. It does not provide any additional feature.
> However, it gives users ability to detect bugs. It's important gain for
> users also.
>
> Wrong code should be fixed anyway. The RFC could be more old code friendly
> if E_DEPECATED is used.
On 16 March 2015 at 08:48, Lester Caine wrote:
> The problem here is simply that just what error's are enabled and
> disabled is getting more difficult to decide? If when moving from a
> currently clean environment which has every error displayed and only
> shows something when any problem arises
Hi Lester,
On 16 March 2015 at 08:04, Lester Caine wrote:
> On 16/03/15 00:16, Marco Pivetta wrote:
> > Syntactic sugar won't really make things easier when adopting the
> language,
> > and I don't like this sort of additional cognitive load either.
> >
> > In short, I stand firm on my "if you c
On 16 March 2015 at 08:04, Lester Caine wrote:
>
> Some of this Syntactic sugar would in the past have been developed in
> PEAR, but the support for 'userland' solutions via that path seems to
> have lost favour, with even the suggestion that PEAR should be dropped?
> Perhaps if PEAR contained exa
Hi,
On Mar 16, 2015 4:29 PM, "Xinchen Hui" wrote:
>
> Hey:
>
> The most unaccept feature in current STH thing(v.5.0) is this.
>
> acutaly, I believe in most applications, they will still keep this
off..
>
> so why we introduce such thing?
>
> beside this, I have a question, w
Hey:
On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye wrote:
> Hi,
>
> On Mar 16, 2015 4:29 PM, "Xinchen Hui" wrote:
>>
>> Hey:
>>
>> The most unaccept feature in current STH thing(v.5.0) is this.
>>
>> acutaly, I believe in most applications, they will still keep this
>> off..
>>
>>
On 16/03/15 08:51, Marco Pivetta wrote:
> On 16 March 2015 at 08:48, Lester Caine wrote:
>
>> > The problem here is simply that just what error's are enabled and
>> > disabled is getting more difficult to decide? If when moving from a
>> > currently clean environment which has every error display
On 16/03/15 08:55, Marco Pivetta wrote:
> PEAR surely isn't where you'd look for new code nowadays: it's a legacy
> repository.
Give me an alternative?
I've had to update my own cope of PEAR so it's clean E_STRICT, but it is
still essential to maintain legacy code bases which are not going
anywher
On Mon, 16 Mar 2015 12:09:42 +0300, Lester Caine
wrote:
On 16/03/15 08:55, Marco Pivetta wrote:
PEAR surely isn't where you'd look for new code nowadays: it's a legacy
repository.
Give me an alternative?
I've had to update my own cope of PEAR so it's clean E_STRICT, but it is
still essenti
On 16/03/15 08:59, Leigh wrote:
> And how do you propose the lexer/parser is extended in this manner?
'Some of this Syntactic sugar' ... Things like the sort interface and
other userland stuff and there are tidy ways to do 'in' with existing
code. Most of the time mine has already been run in the
On 15 March 2015 at 15:46, Nikita Popov wrote:
> Hi internals!
>
> To ensure we have no shortage of new RFC votes...
>
> https://wiki.php.net/rfc/reclassify_e_strict#vote
>
> Voting is open for ten days :)
>
Nikita, don't forget to start a new thread with the tag [VOTE] in the
subject line a
Hi,
working on bug 68486 I had a look at the apache2handler virtual() function.
This function, as vaguely documented, is intended to make an Apache
subrequest, without terminating the currently running request, i.e. run
whatever is behind a different URI (given as an argument to virtual().
The
On 16/03/15 09:14, Nikita Nefedov wrote:
> There are composer [1] and pickle [2].
>
> Please refrain from your over-frequent comments in this mailing list
> before doing research on the subject, you tend to create an
> informational noise when you do this.
So it is now official PHP policy that we
On Monday 16 March 2015 10:31:46 Patrick Schaaf wrote:
>
> Furthermore, I have a working prototype of changing the behaviour of
> virtual() in the following way: _remember_ which subrequest should be made,
> but then only really make it when the current request ends (php_handler()
> in the apache2h
On 16 March 2015 at 01:40, Wei Dai wrote:
> Hi internals,
>
> The RFC to add a user-land function for an easy-to-use and reliable
> preg_replace_callback_array() in PHP is up for discussion:
> https://wiki.php.net/rfc/preg_replace_callback_array
>
> This proposes adding one function: `preg_replac
On Fri, Mar 13, 2015 at 9:33 PM, Stelian Mocanita wrote:
> So to get it clear for everyone: the right way is for internals to ignore
> community as a
> whole, stick to their own views and implement something nobody actually
> wants
Few people already told - they like this.
Thanks. Dmitry.
>
We all have established ways of working, and my own is based on SUSE as
the core OS having switched around a little over the last few years and
simply ended up back with what is simply 'comfortable'. I can control
the remote servers without a problem and keep them up to date security
wise via the S
Hi Pierre,
On Mon, Mar 16, 2015 at 5:17 PM, Pierre Joye wrote:
> On Mar 16, 2015 6:46 PM, "Yasuo Ohgaki" wrote:
> >
> > Hi Dennis,
> >
> > On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz
> > wrote:
> >
> > > Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:
> > > > Caller _must_ satisfy callee req
On 16 March 2015 at 09:05, Xinchen Hui wrote:
> Hey:
> I don't like strict_types at all..
>
And you would never be forced to use them.
But you're voting against allowing anyone else to use them. :-(
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
Maintaining the documentation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 16 Mar 2015, Xinchen Hui wrote:
> On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye wrote:
> >
> > On Mar 16, 2015 4:29 PM, "Xinchen Hui" wrote:
> >>
> >> that means, I need to add a lots of (int) while I try to call a
> >> function in a library which is not written by myself.
> >>
> >>
On Mon, 16 Mar 2015, Yasuo Ohgaki wrote:
> On Mon, Mar 16, 2015 at 5:17 PM, Pierre Joye wrote:
>
> > On Mar 16, 2015 6:46 PM, "Yasuo Ohgaki" wrote:
> > >
> > > On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz
> > > wrote:
> > >
> > > > Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:
> > > >
> > >
Hey:
On Mon, Mar 16, 2015 at 7:18 PM, Derick Rethans wrote:
> On Mon, 16 Mar 2015, Xinchen Hui wrote:
>
>> On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye wrote:
>> >
>> > On Mar 16, 2015 4:29 PM, "Xinchen Hui" wrote:
>> >>
>> >> that means, I need to add a lots of (int) while I try to call a
Hi Derick,
On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans wrote:
> On Mon, 16 Mar 2015, Xinchen Hui wrote:
>
> > On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye
> wrote:
> > >
> > > On Mar 16, 2015 4:29 PM, "Xinchen Hui" wrote:
> > >>
> > >> that means, I need to add a lots of (int) while I
On Mon, Mar 16, 2015 at 7:32 PM, Xinchen Hui wrote:
> Hey:
>
> On Mon, Mar 16, 2015 at 7:18 PM, Derick Rethans wrote:
>> On Mon, 16 Mar 2015, Xinchen Hui wrote:
>>
>>> On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye wrote:
>>> >
>>> > On Mar 16, 2015 4:29 PM, "Xinchen Hui" wrote:
>>> >>
>>> >>
Hey:
On Mon, Mar 16, 2015 at 7:33 PM, Yasuo Ohgaki wrote:
> Hi Derick,
>
> On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans wrote:
>>
>> On Mon, 16 Mar 2015, Xinchen Hui wrote:
>>
>> > On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye
>> > wrote:
>> > >
>> > > On Mar 16, 2015 4:29 PM, "Xinchen Hui"
Hi Nikic,
On 15/03/2015 19:30, Matteo Beccati wrote:
In PHP4 times it was in fact quite common to change inherited method
signatures to bend them to one's will and/or remove parameters and
hardcode them in the parent constructor call. We now know it is bad
practice, but I bet there's lot of code
On Mon, 16 Mar 2015 14:33:00 +0300, Yasuo Ohgaki
wrote:
Hi Derick,
On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans wrote:
To be frank, I don't think "I don't like this" is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefi
>>
>> This RFC will have serious consequence. We made mistake with
>> "safe_mode". The main reason it failed is "it did not force caller to
>> have responsibility to make it work as it should". This RFC does the
>> same for how declare(strict_types=1) works.
>>
>> Aren't we learned from "safe_mode"
On Mon, Mar 16, 2015 at 8:44 PM, Nikita Nefedov wrote:
> On Mon, 16 Mar 2015 14:33:00 +0300, Yasuo Ohgaki
> wrote:
>
> Hi Derick,
>>
>> On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans wrote:
>>
>> To be frank, I don't think "I don't like this" is a terribly good reason
>>> to vote against (or
>> On 14 Mar 2015, at 6:41 am, Lester Caine wrote:
>>
>> On 13/03/15 18:53, guilhermebla...@gmail.com wrote:
>> By considering PHP's nature, having a dual mode is a WTF. I can see myself
>> asking multiple times a day "is this file strict or not?" to trace
>> potential bugs or type juggling. I d
On 16 March 2015 at 11:49, Pavel Kouřil wrote:
>>>
>
> Seriously, think about it for a while - when some setting that changes
> how code behaves was a good idea?
The problem is that there are two irreconcilable camps - some people
want weak STHs, other people want strict STHs.
This RFC gives bo
On 16/03/2015 11:49, Pavel Kouřil wrote:
it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the "intent" is the same - a switch changing how code
behaves.
ini_set('memory_limit', 10); also changes how your code behave, but it's
global so that can be problematic.
On 16 March 2015 at 02:31, Marcio Almada wrote:
> There was no need to update the BC break section. The only minor change was
> the addition of the following section:
>
Yeah, really strong -1 on this one, even after the modification.
Now that the RFC only covers static calling, all of the code i
On Mon, 16 Mar 2015, Pavel Kouřil wrote:
> >> This RFC will have serious consequence. We made mistake with
> >> "safe_mode". The main reason it failed is "it did not force caller
> >> to have responsibility to make it work as it should". This RFC does
> >> the same for how declare(strict_types=
On Mon, Mar 16, 2015 at 1:04 PM, Dan Ackroyd wrote:
> On 16 March 2015 at 11:49, Pavel Kouřil wrote:
>>
>> Seriously, think about it for a while - when some setting that changes
>> how code behaves was a good idea?
>
>
> The problem is that there are two irreconcilable camps - some people
>
On Mon, Mar 16, 2015 at 12:49 PM, Pavel Kouřil wrote:
> Hello,
>
> it's similiar to the safe_mode though. Sure, it's not as bad as INI
> setting, but the "intent" is the same - a switch changing how code
> behaves.
>
> When I talked about the Dual Mode with some friends who are userland
> PHP dev
On Mon, Mar 16, 2015 at 11:33 AM, Yasuo Ohgaki wrote:
> Hi Derick,
>
> On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans wrote:
>
> > On Mon, 16 Mar 2015, Xinchen Hui wrote:
> >
> > > On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye
> > wrote:
> > > >
> > > > On Mar 16, 2015 4:29 PM, "Xinchen Hui" w
On Mon, 16 Mar 2015, Jordi Boggiano wrote:
> On 16/03/2015 11:49, Pavel Kouřil wrote:
> > it's similiar to the safe_mode though. Sure, it's not as bad as INI
> > setting, but the "intent" is the same - a switch changing how code
> > behaves.
>
> ini_set('memory_limit', 10); also changes how your
Hi Matteo,
On 16.03.15 12:43, Matteo Beccati wrote:
> On 15/03/2015 19:30, Matteo Beccati wrote:
>> In PHP4 times it was in fact quite common to change inherited method
>> signatures to bend them to one's will and/or remove parameters and
>> hardcode them in the parent constructor call. We now kno
On Mon, 16 Mar 2015 14:50:16 +0300, Yasuo Ohgaki
wrote:
I already showed real world example how this could be fail.
If we need this kind of behavior. I would suggest to have type affinity
like SQLite for
$_GET/$_POST/$_COOKIE.
https://www.sqlite.org/datatype3.html
This would work better t
On Mon, 16 Mar 2015, Yasuo Ohgaki wrote:
> On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans wrote:
>
> > On Mon, 16 Mar 2015, Xinchen Hui wrote:
> >
> > > On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye wrote:
> > > >
> > > > On Mar 16, 2015 4:29 PM, "Xinchen Hui" wrote:
> > > >>
> > > >> tha
On Mon, 16 Mar 2015, Xinchen Hui wrote:
> And last comment, if there no such declare thing, I will definitely
> vote yes to this RFC.
>
> that's why I want vote no for this, and wait for Bob's Basic STH.
That will not be in PHP 7.0 though, as the deadline passed.
And I can probably bet on tha
On Monday, March 16, 2015, Derick Rethans wrote:
> On Mon, 16 Mar 2015, Jordi Boggiano wrote:
>
>> On 16/03/2015 11:49, Pavel Kouřil wrote:
>> > it's similiar to the safe_mode though. Sure, it's not as bad as INI
>> > setting, but the "intent" is the same - a switch changing how code
>> > behaves.
On 15 March 2015 at 19:19, Marcio Almada wrote:
> Hi
>> It's also going to be impossible for people to try the patch out, or
>> to measure it for performance hit.
>>
>
> Performance has never been an issue with this RFC. You probably meant "bc
> break" not "performance hit", and the suggested chan
On 16/03/2015 13:28, Markus Fischer wrote:
am I correct assuming that your existing test suite was running with
E_STRICT excluded from error_reporting ?
Of course.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing
Le 16/03/2015 12:39, Xinchen Hui a écrit :
Hey:
And last comment, if there no such declare thing, I will definitely
vote yes to this RFC.
Hi Xinchen,
You can also not vote at all, that's a very valid option.
By voting yes, you say that you want PHP developers to have access to
STH in PHP
On 16/03/15 11:54, David Muir wrote:
>>> On 14 Mar 2015, at 6:41 am, Lester Caine wrote:
>>> >>
>>> >> On 13/03/15 18:53, guilhermebla...@gmail.com wrote:
>>> >> By considering PHP's nature, having a dual mode is a WTF. I can see
>>> >> myself
>>> >> asking multiple times a day "is this file str
On 3/15/15 11:05 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Mon, Mar 16, 2015 at 11:50 AM, Eli wrote:
>> Currently, I can speak for myself, I almost always find myself doing a
>> 'backup' step in coding. Because in this situation my process becomes:
>>
>> if ($zebra ... Oh wait, can't do that, nee
On 3/16/15 2:21 AM, Stanislav Malyshev wrote:
> > if ($zebra in $zoo) {}
> Two things here:
>
> 1. If you're looking whether your zoo has a zebra, and you're doing it
> by inspecting every inch of your zoo and checking if it doesn't contain
> a zebra by any chance, you're running your zoo wrong. I
On 15 March 2015 at 15:23, Levi Morrison wrote:
> On Sun, Mar 15, 2015 at 8:29 AM, Michael Wallner wrote:
> >
> >> On 15 03 2015, at 15:19, Anthony Ferrara wrote:
> >>
> >> All,
> >>
> >> I ran some numbers on the current votes of the dual-mode vote right
> >> now. There were a number of voters
> On 15.03.2015, at 15:19, Anthony Ferrara wrote:
>
> kk - no
That is me. And I voted no on a broken poposal.
K
--
Kristian Köhntopp http://google.com/+KristianKohntopp
signature.asc
Description: Message signed with OpenPGP using GPGMail
>> On 16 Mar 2015, at 11:16 pm, Pavel Kouřil wrote:
>>
>> On Mon, Mar 16, 2015 at 1:04 PM, Dan Ackroyd wrote:
>>> On 16 March 2015 at 11:49, Pavel Kouřil wrote:
>>>
>>> Seriously, think about it for a while - when some setting that changes
>>> how code behaves was a good idea?
>>
>>
>> The
On Sun, Mar 15, 2015 at 10:07 PM, Yasuo Ohgaki wrote:
> Hi Netroby,
>
> On Mon, Mar 16, 2015 at 12:03 PM, Netroby wrote:
>
> > Does the "in" support this kind of php code ?
> >
> > ```php
> > > $arr = ['a', 'b', 'c'];
> > for ($v in $arr) {
> > echo $v;
> > }
> >
> >
> > ```
> >
> > I know
> On 16.03.2015, at 15:03, Kristian Köhntopp wrote:
>
> That is me. And I voted no on a broken poposal.
And because some people asked, the kk account is not new.
I have been using PHP since about 1997/98, joining the community around the
times of the first PHP 3.0 beta-releases. Boris Erdmann
Hey:
On Mon, Mar 16, 2015 at 9:32 PM, Pascal Chevrel wrote:
> Le 16/03/2015 12:39, Xinchen Hui a écrit :
>>
>> Hey:
>
>
>>
>> And last comment, if there no such declare thing, I will definitely
>> vote yes to this RFC.
>
>
> Hi Xinchen,
>
> You can also not vote at all, that's a very valid optio
Hey David,
> A library written in weak or strict mode will have no bearing on its public
> API.
Strictly speaking (pun intended), this is not true. A library can easily expose
a
facade that enforces a user of that library (who is in weak mode) to have to
write
in strict mode [1]. Once more, thi
Hey:
On Mon, Mar 16, 2015 at 10:21 PM, Zeev Suraski wrote:
> All,
>
>
>
> After much thinking, and despite grave concerns I raised about what
> transpired in the last 24 hours, I decided to get behind the Dual Mode RFC
> at this time.
>
>
>
> I call upon everyone - both people that haven’t yet vo
On Monday March 16 at 9:33 am Thomas Punt wrote:
> Strictly speaking (pun intended), this is not true. A library can easily
> expose a
> facade that enforces a user of that library (who is in weak mode) to have to
> write
> in strict mode [1]. Once more, this can be done unintentionally [2] beca
On 16/03/2015 14:45, Theodore Brown wrote:
On Monday March 16 at 9:33 am Thomas Punt wrote:
Strictly speaking (pun intended), this is not true. A library can easily expose
a
facade that enforces a user of that library (who is in weak mode) to have to
write
in strict mode [1]. Once more, this
Thank you Zeev.
On 16 March 2015 at 14:35, Xinchen Hui wrote:
> Unecessary for everybody, one or two change from no to yes will make it pass.
> :)
Although not necessary, it would reduce the level of drama, which
would be a good thing.
cheers
Dan
--
PHP Internals - PHP Runtime Development M
> On 16.03.2015, at 15:45, Theodore Brown wrote:
>
> This is a bug in the library. It declares strict mode but passes a value it
> does not know to be an integer to a method requiring an integer. It can
> be fixed by simply adding an int type declaration to the constructor or
> test method.
It
Hey,
> This is a bug in the library. It declares strict mode but passes a value it
> does not know to be an integer to a method requiring an integer. It can
> be fixed by simply adding an int type declaration to the constructor or
> test method.
The second example is certainly a programmer error,
Hey:
On Mon, Mar 16, 2015 at 5:45 PM, Peter Cowburn wrote:
> On 16 March 2015 at 01:40, Wei Dai wrote:
>
>> Hi internals,
>>
>> The RFC to add a user-land function for an easy-to-use and reliable
>> preg_replace_callback_array() in PHP is up for discussion:
>> https://wiki.php.net/rfc/preg_repla
All,
After much thinking, and despite grave concerns I raised about what
transpired in the last 24 hours, I decided to get behind the Dual Mode RFC
at this time.
I call upon everyone - both people that haven’t yet voted and those who
voted no - to do the same so that we ensure that we have ST
On 16 March 2015 at 04:58, Levi Morrison wrote:
> Dear Internals,
>
> I am tentatively opening the vote on this RFC:
> https://wiki.php.net/rfc/reserve_more_types_in_php_7
>
> It's a bit tentative because I would prefer to wait until the vote on
> Anthony's RFC closes tomorrow as there is some ov
On 16 March 2015 at 14:59, Xinchen Hui wrote:
> Hey:
>
> On Mon, Mar 16, 2015 at 5:45 PM, Peter Cowburn
> wrote:
> > On 16 March 2015 at 01:40, Wei Dai wrote:
> >
> >> Hi internals,
> >>
> >> The RFC to add a user-land function for an easy-to-use and reliable
> >> preg_replace_callback_array()
Hey:
On Mon, Mar 16, 2015 at 11:32 PM, Peter Cowburn wrote:
> On 16 March 2015 at 14:59, Xinchen Hui wrote:
>
>> Hey:
>>
>> On Mon, Mar 16, 2015 at 5:45 PM, Peter Cowburn
>> wrote:
>> > On 16 March 2015 at 01:40, Wei Dai wrote:
>> >
>> >> Hi internals,
>> >>
>> >> The RFC to add a user-land fu
On 16.03.2015 01:08, Jordi Boggiano wrote:
On 15/03/2015 22:27, Derick Rethans wrote:
On Sun, 15 Mar 2015, Zeev Suraski wrote:
I don't think it's going to far, if you have people with no clue
writing
this:
https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB
Do you know who Kris
Zitat von Marcio Almada :
Hi,
As promised, the "Strict Argument Count" RFC vote was restarted:
RFC: https://wiki.php.net/rfc/strict_argcount
PR: https://github.com/php/php-src/pull/1108
There was no need to update the BC break section. The only minor change was
the addition of the following
Hi everyone,
I know it's late for the RFC party, but it looks like some form of STH
is going to land in PHP7. Without reflection support, which is also
missing from return types as far as I know.
That's why I'm resuming this thread, as I still think this is the best
approach. Many do not lik
Hi,
I had no time to reply all emails since yesterday, but right now we are
having a voting with 2 "yes" votes vs 16 "no" votes.
I think we all agree that the RFC won't pass and I'm withdrawing the RFC
for the following reasons:
1. The sooner we end the voting period the better for the PHP ti
If I see the results properly, it makes bout 5% improvement. Right?
Definitly makes sense to commit.
Let me know when you finish testing, or like me to commif this as is.
If someone see some troubles let us know.
Note, that the patch affects only Windows.
Thanks. Dmitry.
On Mar 16, 2015 6:23 PM,
While you can easily question the value or motives of Anthony's post
about voting irregularities, some simple improvements can be made
which are uncontroversial. I consider this a low hanging fruit, like
restricting the sale of firearms to people who are clearly drunk.
I mentioned on that other th
Hi all,
Am 16.03.2015 um 19:01 schrieb Philip Sturgeon:
> I mentioned on that other thread that the FIG has a rule saying you
> cannot cast a vote in any vote that was initiated before your
> membership was activated.
> Let's just shove that rule in the wiki and call it done.
when we are fixing t
Hi Thomas,
Am 16.03.2015 um 15:33 schrieb Thomas Punt:
> A library can easily expose a facade that enforces a user of that library
> (who is in weak mode) to have to write in strict mode [1]. Once more,
> this can be done unintentionally [2] because of the
> caller-deciding semantics. These exampl
On Mon, March 16, 2015 18:17, Dmitry Stogov wrote:
> If I see the results properly, it makes bout 5% improvement. Right?
> Definitly makes sense to commit.
> Let me know when you finish testing, or like me to commif this as is.
>
I've just pushed your patch along with some tests I did to ensure
fun
Hi!
> when we are fixing the low hanging fruits, please directly put in the
> wiki that the closing time of a vote has to be announced as a UTC time
> so there is no confusion when a day ends.
Good point. I'd still allow other times besides UTC if it's convenient
to the RFC author, but UTC one sh
Hi all,
On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz
wrote:
> Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
> > lib.php
> > >declare(strict_types = 1);
> >function add(int $a, int $b) {
> >}
> >
> > > add($_GET['a'], $_GET['b']);
> >
> > that
Hi all,
I think this is important, but not many people realize the importance.
Therefore I created this as a new thread at the last minutes of vote.
On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz
wrote:
> Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
> > lib.php
> > >declare
On March 16, 2015 2:32:39 PM GMT+01:00, Pascal Chevrel
wrote:
>It's too late, Bob's Basic STH missed the schedule for PHP 7, it was
>proposed way too late and the coercive STH RFC has just zero chance to
>pass, it's too much of a BC break for everybody. The dual mode STH is
>the only chance
On Mon, Mar 16, 2015 at 2:12 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz
> wrote:
>
> > Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
> > > lib.php
> > > > >declare(strict_types = 1);
> > >function add(int $a, int $b) {
> > >
> On 17 Mar 2015, at 1:33 am, Thomas Punt wrote:
>
> Hey David,
>> A library written in weak or strict mode will have no bearing on its public
>> API.
>
> Strictly speaking (pun intended), this is not true. A library can easily
> expose a
> facade that enforces a user of that library (who is
On Mon, Mar 16, 2015 at 8:53 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> I think this is important, but not many people realize the importance.
> Therefore I created this as a new thread at the last minutes of vote.
>
> On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz
> wrote:
>
>> Am 16.03.2015 um 06
On Mon, Mar 16, 2015 at 2:53 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> I think this is important, but not many people realize the importance.
> Therefore I created this as a new thread at the last minutes of vote.
>
...
>
> "strict_mode" is just controlling errors, then it should be named as error
> c
> No, your example would blow up regardless of the caller being in strict mode
> or weak mode.
That was the point in my hypothetical example - the library can decide
what mode it wants the user to use (strict or weak) if it wants to.
-Tom
--
PHP Internals -
Hi Matthew and all,
On Tue, Mar 17, 2015 at 5:34 AM, Matthew Leverton
wrote:
> On Mon, Mar 16, 2015 at 2:53 PM, Yasuo Ohgaki wrote:
> > Hi all,
> >
> > I think this is important, but not many people realize the importance.
> > Therefore I created this as a new thread at the last minutes of vote
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
On Mon, Mar 16, 2015 at 5:04 PM Anthony Ferrara wrote:
> All,
>
> Voting has been closed on the scalar type declarations v0.5 RFC:
>
> https://wiki.php.net/rfc/scalar_type_hints_v5
>
> At a final score of 108:48, it has been accepted for PHP 7.
>
> Thank you.
>
> Anthony
>
> --
> PHP Internals -
On 3/16/15 4:03 PM, Anthony Ferrara wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
Huzzah! Huge props to everyone that made this happen
Thank you Andrea and Anthony. Your efforts are much appreciated!
- Jon
On Mon, Mar 16, 2015 at 4:03 PM, Anthony Ferrara
wrote:
> All,
>
> Voting has been closed on the scalar type declarations v0.5 RFC:
>
> https://wiki.php.net/rfc/scalar_type_hints_v5
>
> At a final score of 108:48, it has bee
Hi all,
I had this idea for a long time, but I didn't have time to mention.
Since I did mention this idea in basic type hints thread, I've
created RFC for it.
https://wiki.php.net/rfc/introduce-type-affinity
SQLite2 was typeless. All data is stored as "text".
Type affinity is SQLite3's idea to h
1 - 100 of 117 matches
Mail list logo
