Hi Yasuo,
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
> scripts
> that are prepared for type safety is "ignored" and it leads s
The voting period for the "Even More" type hints reservation RFC is now open.
Reminder, any types reserved via this RFC are dependent on at least
one of the STH RFCs passing, or Levi's base types reservation RFCs
passing as it's silly without at least one of those.
https://wiki.php.net/rfc/reserv
Hey:
On Mon, Mar 16, 2015 at 2:35 PM, Sebastian Bergmann wrote:
> Am 15.03.2015 um 16:36 schrieb Sebastian Bergmann:
>> Over in Room 11, Michael just pointed out that this could be related
>> to php_stdint.h.
>
> Okay, this does not seem to be related to the GCC version but rather
> to the fact
Am 15.03.2015 um 16:36 schrieb Sebastian Bergmann:
> Over in Room 11, Michael just pointed out that this could be related
> to php_stdint.h.
Okay, this does not seem to be related to the GCC version but rather
to the fact that some int types etc. are not defined on/for my platform.
If I use -Di
Hi!
> 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.
That makes a lot of sense, though I don't think we had much of this
issue. Fi
Hi all,
On Mon, Mar 16, 2015 at 3:03 PM, Matthew Leverton
wrote:
> On Mon, Mar 16, 2015 at 12:55 AM, Xinchen Hui wrote:
> > That is why I don't see it before (thousand times, too long to read...
> > but not in RFC)
> >
> It's in the RFC: "Whether or not the function being called was
> declared
Hey:
On Mon, Mar 16, 2015 at 2:03 PM, Matthew Leverton wrote:
> On Mon, Mar 16, 2015 at 12:55 AM, Xinchen Hui wrote:
>> That is why I don't see it before (thousand times, too long to read...
>> but not in RFC)
>>
> It's in the RFC: "Whether or not the function being called was
> declared in a fi
Hi!
> But I'd like to know from your POV: Does this harm anything?
Depends on what you see as "harm". Complicating the language is kind of
harm. Introducing stuff that promotes patterns that are not always best,
and that do a bit too much, and look too much like something in
different languages
On Mon, Mar 16, 2015 at 12:55 AM, Xinchen Hui wrote:
> That is why I don't see it before (thousand times, too long to read...
> but not in RFC)
>
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 checkin
Hey:
On Mon, Mar 16, 2015 at 9:40 AM, 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: `
Hey:
On Mon, Mar 16, 2015 at 1:49 PM, Dennis Birkholz wrote:
> Hello Xinchen,
>
> 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']);
>>
>>
Hello Xinchen,
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 means, I need to add a lots of (int) while I try to call a
> function
Hi Pierre,
On Mon, Mar 16, 2015 at 12:31 PM, Pierre Joye wrote:
> > I'm not saying the proposed patch has bugs, but I'm saying it hides
> "users' code bugs".
> >
> > Hiding hard to find bugs does not make much sense while there is the
> proposal that finds it.
> > What I'm trying to say is "Why
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, which is not explained in the RFC:
lib.php
assuming
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 overlap in the type
names reserved. However, I am unsure if I am
On Mar 16, 2015 1:17 PM, "Yasuo Ohgaki" wrote:
>
> Hi Pierre,
>
> On Mon, Mar 16, 2015 at 10:48 AM, Pierre Joye
wrote:
>>
>> > Coercive type for general developers and strict type for library
developers
>> > will
>> > eliminate more type related bugs, more natural to average PHP users.
IMHO.
>>
>
Hi Stas,
On Mon, Mar 16, 2015 at 7:41 AM, Stanislav Malyshev
wrote:
> > The section about '"Flexible" Interface Implementations' mentions the
> > interface as an 'an acceptable “PHPism”'.
> >
> > This is not just an "acceptable PHPism", it's a "life saving PHPism".
> /.../
> > Getting this chang
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, but a simple rule saying "You cannot
vote on any RFC start
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 javascript has this kind of support
>
>
> https://developer.mozilla.org/en-US/docs/Web/J
Hi all,
On Mon, Mar 16, 2015 at 11:50 AM, Eli wrote:
> On 3/14/15 10:34 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>
> I'd like to announce that I'll open the vote for the in operator later that
> day.
> You can find the RFC here: https://wiki.php.net/rfc/in_operator
>
> I think this operator is
Does the "in" support this kind of php code ?
```php
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in
Appreciate your time.
Netroby
2015-03-16 10:50 GMT+08:00 Eli :
> On 3/14/15 10:34 PM, Stanislav Malyshev wrote:
>
> Hi!
>
> I'd
On 3/14/15 10:34 PM, Stanislav Malyshev wrote:
> Hi!
>
>> I'd like to announce that I'll open the vote for the in operator later that
>> day.
>> You can find the RFC here: https://wiki.php.net/rfc/in_operator
> I think this operator is unnecessary - we already have perfectly good
> function that d
Hi Dennies,
On Mon, Mar 16, 2015 at 11:36 AM, Dennis Birkholz
wrote:
> Am 16.03.2015 um 03:16 schrieb Yasuo Ohgaki:
> > This code is an example that I posted in other thread.
> >
> > e.g.
> > > function check_num_range(int $num) { if ($num < 0 || $num > 100)
> > trigger_error('Invalid range');
Hi all,
Am 16.03.2015 um 03:16 schrieb Yasuo Ohgaki:
> This code is an example that I posted in other thread.
>
> e.g.
> function check_num_range(int $num) { if ($num < 0 || $num > 100)
> trigger_error('Invalid range'); }
> // Somewhere far from function definition.
> $num = $GET['num'];
> // So
Hi all,
On Mon, Mar 16, 2015 at 11:16 AM, Yasuo Ohgaki wrote:
>
>
>>
>> > It's natural that we have different point of views, but we can easily
>> > understand/guess
>> > the consequence of the RFC. Weak mode is simply too weak to be useful.
>> > Strict mode will hide type bugs by errorless cast
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 section:
https://wiki.php.net
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_replace_callback_array()` that
is the better way to Implement
Hello Pierre,
Am 16.03.2015 um 02:34 schrieb Pierre Joye:
> "Some of the strict standards notices are converted to an error
> category that is considered more severe. As such error handlers might
> treat it more severely, resulting in BC breakage."
>
> Does it mean that some errors may end on rec
Hi Pierre,
On Mon, Mar 16, 2015 at 10:48 AM, Pierre Joye wrote:
> > Coercive type for general developers and strict type for library
> developers
> > will
> > eliminate more type related bugs, more natural to average PHP users.
> IMHO.
>
> And change casting rules, open a pandora box. And even w
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_replace_callback_array()` that
is the better way to Implem
On Mon, Mar 16, 2015 at 12:40 PM, Yasuo Ohgaki wrote:
> Hi Anthony,
>
> On Mon, Mar 16, 2015 at 6:33 AM, Anthony Ferrara
> wrote:
>
>> I have decided to close the vote on my Scalar type declarations RFC.
>>
>> When I added the wording "or the date that voting closes on a
>> competing RFC." to the
Hi Anthony,
On Mon, Mar 16, 2015 at 6:33 AM, Anthony Ferrara
wrote:
> I have decided to close the vote on my Scalar type declarations RFC.
>
> When I added the wording "or the date that voting closes on a
> competing RFC." to the voting timeline of the RFC, it was in the
> understanding that it
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_replace_callback_array()` that
is the better way to Implem
hi Nikita,
On Mon, Mar 16, 2015 at 2:46 AM, 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 :)
I am late on that but I need one clarification about:
"Some of the s
> You have to enter the email address of this mailing list into the fourth
> field of the form.
Just gave that a try, no error message. still goes back to the form.
On Sun, Mar 15, 2015 at 5:01 PM, Christoph Becker wrote:
> Admin Admin wrote:
>
> > first of all https://wiki.php.net/start?do=reg
On Mon, Mar 16, 2015 at 10:08 AM, 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/p
Hi Niklas,
On 15 March 2015 at 19:31, Niklas Keller wrote:
> Morning,
>
> I just opened the vote for the in operator, you can find the RFC here:
> https://wiki.php.net/rfc/in_operator
> Vote will be open for two weeks, counting from today.
>
> Regards, Niklas
>
I just wanted to clarify on my "
On Sat, Mar 14, 2015 at 4:30 PM, Rasmus Lerdorf wrote:
> On 03/15/2015 07:31 AM, Philip Sturgeon wrote:
>> On Sat, Mar 14, 2015 at 7:38 AM, Bob Weinand wrote:
Am 14.03.2015 um 10:21 schrieb Pavel Kouřil :
On Saturday, March 14, 2015, Levi Morrison wrote:
> RFC Link: https://wi
On Mar 16, 2015 2:41 AM, "Michael Wallner" wrote:
>
>
> > On 15 03 2015, at 16:36, Sebastian Bergmann wrote:
> >
> > Am 15.03.2015 um 15:34 schrieb Sebastian Bergmann:
> >> I am asking because using GCC 2.95.3 and GCC 3.4.0 I get errors related
> >> to the usage of intptr_t (see http://pastebin.c
On Mar 16, 2015 8:41 AM, "Zeev Suraski" wrote:
>
> Stelian,
>
> Respectfully, I think internals@ is being just a bit too uptight here.
> First, I did ask Bob before doing this, and while he said he thought it
> wasn't a good idea (mostly because of feedback such as yours) - he didn't
> 'block' me.
On 15/03/15 21:33, Anthony Ferrara wrote:
> However, it has become exceedingly clear to me that this good faith
> has not been reciprocated. The understanding that we had when both
> proposals opened has now been violated. Rules have been broken and
> politics are ensuing in an attempt to sabotage
On 15 March 2015 at 22:56, Stanislav Malyshev wrote:
>
> if
> running PRNG for "too long" is dangerous, wouldn't we already have much
> more serious problem with encryption routines based on them which
> basically do it all the time?
Indeed we would, it's the kind of issue that would get solved
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 Kristian is and how instrumental he was in the
p
On 15 March 2015 at 21:58, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Sunday, March 15, 2015 11:34 PM
>> To: internals@lists.php.net
>> Subject: [PHP-DEV] [RFC][Status] Scalar Type Declarations Voting Date
>> Change
>>
>> Howeve
Hi!
> I want to vote yes, but naming is something that scares me a bit.
> Without any indication that it's CSPRNG, people might start using it
> even when unnecessary, and I'd be worried about potential negative
> effects, such as exhausting the entropy pool. It's probably more of a
After reading
On 15/03/15 21:32, Stelian Mocanita wrote:
> I voted no just because at this point no matter which way STH goes, it
> will end bad so I would rather not have it until people reconcile on
> something that works for all parties.
There does seem to be a general assumption that a 2/3rds majority
actua
Hi!
> The section about '"Flexible" Interface Implementations' mentions the
> interface as an 'an acceptable “PHPism”'.
>
> This is not just an "acceptable PHPism", it's a "life saving PHPism".
/.../
> Getting this change into PHP7 would mean having a major part of the
> framework community havin
On 15/03/2015 19:07, Derick Rethans wrote:
Rowan Collins schreef op 15 maart 2015 17:59:17
GMT+00:00:
On 15/03/2015 14: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 that I didn't recognize. So I
decided
On Mar 16, 2015 9:10 AM, "Pierre Joye" wrote:
>
>
> On Mar 16, 2015 8:58 AM, "Zeev Suraski" wrote:
> >
> > > -Original Message-
> > > From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> > > Sent: Sunday, March 15, 2015 11:34 PM
> > > To: internals@lists.php.net
> > > Subject: [PHP-DEV] [
On 15/03/15 18:16, Niklas Keller wrote:
>> I think allowing `null` for an `int` is an error. Converting a null to
>> > zero on a type boundary is harmful in my opinion.
> I agree, `null` shouldn't be allowed for `int`.
That a database result set will have perfectly valid 'null' returns for
fields
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 Kristian is and how instrumental he was in the
> proliferation of PHP? How
Hi!
>> I think this operator is unnecessary - we already have perfectly good
>> function that does the same.
>
> If they were "perfectly good", ...
I think you forgot to finish your argument here.
>> a set of values. Since efficient implementation of the set in PHP would
>> have the value being
On 15/03/2015 20:52, Johannes Ott wrote:
Am 15.03.2015 um 19:47 schrieb Rowan Collins:
On 15/03/2015 10:41, Johannes Ott wrote:
Okay get your point, but as already discussed several times, the rfc
should not be declined for the reason a ppl, who doesn't understand when
to use static context or
Hi Marcio/internals,
I just went through the RFC again (didn't check the discussion since our
last chat about it in Room 11).
The section about '"Flexible" Interface Implementations' mentions the
interface as an 'an acceptable “PHPism”'.
This is not just an "acceptable PHPism", it's a "life savi
>
>
>
> I asked whether there was anything in the Voting RFC
> (wiki.php.net/rfc/voting) or the Timeline RFC
> (wiki.php.net/rfc/php7timeline), the two RFCs being used to block a Basic
> STH poll from going to a vote for PHP 7.0, that somehow make it legitimate
> for it to be proposed if the Dual M
On Mar 16, 2015 8:58 AM, "Zeev Suraski" wrote:
>
> > -Original Message-
> > From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> > Sent: Sunday, March 15, 2015 11:34 PM
> > To: internals@lists.php.net
> > Subject: [PHP-DEV] [RFC][Status] Scalar Type Declarations Voting Date
> > Change
> >
Hi!
> theory" cries despite Anthony's statement above. As I've already
> indicated, and being a Yes voter, I'm sort of dubious about even my
> own voting rights, and votes of my nature have previously been called
> out as a bad thing by people on both sides of the RFC.
If you think you're not inf
> -Original Message-
> From: Philip Sturgeon [mailto:pjsturg...@gmail.com]
> Sent: Sunday, March 15, 2015 11:12 PM
> To: Zeev Suraski
> Cc: PHP Internals
> Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
>
> > Are there some special rules for a backup
> > plan anywhere in the Voting
FWIW, regardless of the politics and finger pointing here.
I think the only sane way to start solving this is what Anthony has
proposed.
Set a *fair* closing date, with plenty time for both sides to react as they
wish
and let the chips fall where they may.
Its not about Zeev or Anthony or anythin
> -Original Message-
> From: Wim Godden [mailto:wim.god...@cu.be]
> Sent: Sunday, March 15, 2015 11:30 PM
> To: Zeev Suraski
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Voting irregularities
>
>
> On 15/03/2015 20:30, Zeev Suraski wrote:
> >> I don't think it's going to far, if y
Admin Admin wrote:
> first of all https://wiki.php.net/start?do=register seems broken, the form
> submit just returns to the form.
You have to enter the email address of this mailing list into the fourth
field of the form.
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mail
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Sunday, March 15, 2015 11:34 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] [RFC][Status] Scalar Type Declarations Voting Date
> Change
>
> However, it has become exceedingly clear to me that this good
Hi!
> necassary in a strict OOP-world, makes the code more unreadable for the
> simple fact it is more to read.
R u sre mre 2 rd mns hrdr 2 rd?
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mar 16, 2015 6:25 AM, "Zeev Suraski" wrote:
>
> > -Original Message-
> > From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> > Sent: Sunday, March 15, 2015 9:22 PM
> > To: Zeev Suraski
> > Cc: PHP Internals
> > Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
> >
> > Voting for s
Truth be told that might just be a record for number of no votes in a 10
minutes window! :) Also I thought this was all about elephants ...
On Sun, Mar 15, 2015 at 10:40 PM, Zeev Suraski wrote:
> Stelian,
>
> Respectfully, I think internals@ is being just a bit too uptight here.
> First, I did a
Dennis,
On Sun, Mar 15, 2015 at 5:39 PM, Dennis Birkholz wrote:
> Hi Anthony,
>
> Am 15.03.2015 um 22:33 schrieb Anthony Ferrara:
>> Therefore, I am closing votes on this RFC effective tomorrow, March 16th.
>
> could you announce the (UTC) time you close the vote? That is something
> most votes m
Stelian,
Respectfully, I think internals@ is being just a bit too uptight here.
First, I did ask Bob before doing this, and while he said he thought it
wasn't a good idea (mostly because of feedback such as yours) - he didn't
'block' me.
Secondly, can we all relax a bit with the rules, RFCs, lega
Hi Anthony,
Am 15.03.2015 um 22:33 schrieb Anthony Ferrara:
> Therefore, I am closing votes on this RFC effective tomorrow, March 16th.
could you announce the (UTC) time you close the vote? That is something
most votes miss here...
Greets
Dennis
--
PHP Internals - PHP Runtime Development Maili
On 15 March 2015 at 21:09, Admin Admin wrote:
>
> I'll need some help with the patch. I took a look at it once, and since my
> C skills are abhorant, I found myself scratching my head at all the places
> that seem to throw the error message above and what each of them did. So if
> there is anyone
Hi all,
Am 15.03.2015 um 15:19 schrieb Anthony Ferrara:
> ... There were a number of voters that I didn't recognize.
I wondered about who the people are that vote and how they "earned" the
right to do so. I think this kind of confusion could be avoided if
people.php.net would contain a little mor
All,
I have decided to close the vote on my Scalar type declarations RFC.
When I added the wording "or the date that voting closes on a
competing RFC." to the voting timeline of the RFC, it was in the
understanding that it was a good faith effort on the part of Zeev and
the competing RFC for the
Hi!
> voting practices. Anthony specifically notes that he is not calling
> them bad, or calling for them to be ignored in the context of the
He's not calling them bad directly, he is calling them "irregularities",
singling them out and arguing that they are the reason the RFC is
currently does n
I voted no just because at this point no matter which way STH goes, it
will end bad so I would rather not have it until people reconcile on
something that works for all parties.
On Sun, Mar 15, 2015 at 10:21 PM, Pierre Joye wrote:
> On Mar 16, 2015 8:03 AM, "Zeev Suraski" wrote:
> >
> > All,
>
On 15/03/2015 20:30, 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 Kristian is and how instrumental he was in the proliferation
of PHP? How can you bring your
Hi!
> Which post says that we're turning PHP into Java. And to this
> misguided FUD post, that actively asks people to vote no, I can quite
> easily attribute a few more no votes of people that had never voted
> before...
I have seen many messages on the list which I personally consider very
wron
Hi!
> So consider that discussion open.
I guess this would have to happen sooner or later - sooner or later
somebody, when the vote doesn't go their way, would cry "who are all
these people? It can't be right they are all legit, there must be
something wrong". I'm not sure though where this discu
On Sun, Mar 15, 2015 at 10:11 PM, Philip Sturgeon wrote:
>
> I am sorry for hurting your feelings but you are being manipulative
> and I am not a fan of that. I have no agenda, I just want to see you
> put an end to this weird rule bending, definition changing, rule
> ignoring "convenient" interpr
On Mar 16, 2015 8:03 AM, "Zeev Suraski" wrote:
>
> All,
>
>
>
> First, I decided not to propose Basic STH under my name, despite the fact
I
> think that not committing to put it to a vote adds unneeded risk for
> delivering STH in PHP 7.0. Whether or not it’s put to a vote will be up
to
> Bob.
I
Hi,
On 15 March 2015 at 14:19, Anthony Ferrara wrote:
> I'm not saying that all of these are bad votes. Nor that they
> shouldn't be counted. I think it does raise a significant question
> around the voting practices.
I think folk should be cautious about linking the proximity of a
certain RFC t
On Sun, Mar 15, 2015 at 4:44 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Philip Sturgeon [mailto:pjsturg...@gmail.com]
>> Sent: Sunday, March 15, 2015 10:33 PM
>> To: Zeev Suraski
>> Cc: Nikita Popov; PHP Internals
>> Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
>>
>>
Am 15.03.2015 um 12:35 schrieb Crypto Compress:
> You should reread your mails and keep insults to yourself:
>
>> as already discussed several times
>
>> ppl, who doesn't understand
>
>> some beginner who is doing such horiffic code
>
>> maybe think more about what he is doing
>
>> doing 15 years
Now you are just pushing the limits and doing things your way. Bob clearly
stated he does not want a vote and you want with an "unofficial poll"?
You need to learn to let things go their course and not always push matters
your way. I do not see how you can pull this move yet still be offended when
first of all https://wiki.php.net/start?do=register seems broken, the form
submit just returns to the form.
Second of all the crux of my proposal. As many of you know PHP will
transform undefined constants into strings. "Assuming" you meant a string
in bareword. I think there is a lot of danger
All,
First, I decided not to propose Basic STH under my name, despite the fact I
think that not committing to put it to a vote adds unneeded risk for
delivering STH in PHP 7.0. Whether or not it’s put to a vote will be up to
Bob.
Secondly, I do want to attempt to understand what will happen
> -Ursprüngliche Nachricht-
> Von: Matthew Leverton [mailto:lever...@gmail.com]
> Gesendet: Sonntag, 15. März 2015 20:46
> An: Anthony Ferrara
> Cc: internals@lists.php.net
> Betreff: Re: [PHP-DEV] Voting irregularities
>
> On Sun, Mar 15, 2015 at 9:19 AM, Anthony Ferrara wrote:
> > All,
Am 15.03.2015 um 19:47 schrieb Rowan Collins:
> On 15/03/2015 10:41, Johannes Ott wrote:
>> Okay get your point, but as already discussed several times, the rfc
>> should not be declined for the reason a ppl, who doesn't understand when
>> to use static context or when not to use at all, can do cru
> -Original Message-
> From: Philip Sturgeon [mailto:pjsturg...@gmail.com]
> Sent: Sunday, March 15, 2015 10:33 PM
> To: Zeev Suraski
> Cc: Nikita Popov; PHP Internals
> Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
>
> On Sun, Mar 15, 2015 at 4:23 PM, Zeev Suraski wrote:
> >> Sor
On Sun, Mar 15, 2015 at 4:39 PM, Damien Tournoud wrote:
>
> On Sun, Mar 15, 2015 at 9:35 PM, Daniel Lowrey wrote:
>>
>> This is actually a *vastly* inferior solution to language-level support
for generator returns. greenlet/gevent does it this way because these
libraries were created before Pytho
Can we please stop with this? It's damaging to the language and the
community.
I am a strong believer of STH, no surprise there, but I do not think this
thread should have
been created. Is the php voting process uncontrolled and chaotic with no
real count of voting
members? Hell yes.
This does no
On Sun, Mar 15, 2015 at 9:35 PM, Daniel Lowrey wrote:
> This is actually a *vastly* inferior solution to language-level support
> for generator returns. greenlet/gevent does it this way because these
> libraries were created before Python supported generator delegation (and
> continue supporting
Hi Niklas,
To reiterate and explain my no vote:
The RFC is still lacking one thing
- any justification of why this deserves being a new piece of syntax,
rather than just being a function implemented either internally, or
even better in userland PHP.
The equation is not just "will PHP be better
On Sun, Mar 15, 2015 at 4:13 PM, Damien Tournoud wrote:
>
> Hi Daniel,
>
> Would you mind clarifying the relationship between the "Generator
Delegation" RFC and the "Generator Return Expressions" RFC?
>
Sure, thanks for the question. As mentioned in the RFC:
"In short: generator delegation allow
On Sun, Mar 15, 2015 at 4:23 PM, Zeev Suraski wrote:
>> Sorry, but ... even though your original RFC was very unclear about this,
>> everybody went by the "all votes must start by the 15th" interpretation
>> that
>> has been discussed in that thread. Do you think it's an accident that a
>> whoppin
On Sun, Mar 15, 2015 at 11:29 AM, Matteo Beccati wrote:
> On 15/03/2015 04:23, Sammy Kaye Powers wrote:
>
>> A two week discussion period has been held for the reliable user-land
>> CSPRNG RFC to add `random_bytes()` and `random_int()`. The RFC has now
>> been
>> moved into voting.
>>
>> https://
> Sorry, but ... even though your original RFC was very unclear about this,
> everybody went by the "all votes must start by the 15th" interpretation
> that
> has been discussed in that thread. Do you think it's an accident that a
> whopping six RFC votes started today? It isn't.
>
>
> Please don't
2015-03-15 21:13 GMT+01:00 Damien Tournoud :
> Hi Daniel,
>
> Would you mind clarifying the relationship between the "Generator
> Delegation" RFC and the "Generator Return Expressions" RFC?
>
> While I really appreciate the "Generator Delegation" RFC, the "Generator
> Return Expressions" looks bot
Hi Zeev,
On 11 March 2015 at 18:48, Zeev Suraski wrote:
> Rest assured that if I see that they both seem to be failing as we near the
> end of the voting time, I'll retract the Coercive STH RFC - and I'll
> actually vote in favor of the dual mode RFC,
People sometimes tell me that they think th
Hi Daniel,
Would you mind clarifying the relationship between the "Generator
Delegation" RFC and the "Generator Return Expressions" RFC?
While I really appreciate the "Generator Delegation" RFC, the "Generator
Return Expressions" looks both unnecessary and kind of a hack to me. In
evented system
On 15 March 2015 at 13:17, Pádraic Brady wrote:
>
> Were folk to use random_int() by default, it would be actually be
> considerably better than the situation today where many reach for
> mt_rand() without really considering the use case. Using a strong
> source of ints instead of a weak source st
> -Original Message-
> From: Philip Sturgeon [mailto:pjsturg...@gmail.com]
> Sent: Sunday, March 15, 2015 10:07 PM
> To: Niklas Keller
> Cc: Levi Morrison; Bob Weinand; Anthony Ferrara; Zeev Suraski; Stelian
> Mocanita; PHP internals
> Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
>
> On
1 - 100 of 194 matches
Mail list logo
