Hi Ferenc,
Ferenc Kovacs writes:
> Hello!
>
> The PHP development team announces the immediate availability of PHP 5.6.6.
> This release fixes several bugs and addresses CVE-2015-0235 and
> CVE-2015-0273.
> All PHP 5.6 users are encouraged to upgrade to this version.
>
> For source downloads of
Hi internals,
I'd like to put the "Context Sensitive Lexer" RFC into discussion phase:
RFC: https://wiki.php.net/rfc/context_sensitive_lexer
TL;DR commit: https://github.com/marcioAlmada/php-src/commit/c01014f9
PR: https://github.com/php/php-src/pull/1054
PHP currently has ~64 globally reserved
2015-02-12 20:55 GMT-03:00 Stelian Mocanita :
>
>
>
>> I could compromise to send pull requests and update some of these tools
>> (at
>> least the open source ones) in time for PHP7 release.
>>
>
> Print screen taken, will hold you to your words.
>
>
Please do ;) If the RFC passes I'll be happy to
I'm not sure. Currently we don't use namespaces for core classes, but I
won't object to change this.
Nikita, what do you think?
Thanks. Dmitry.
On Fri, Feb 20, 2015 at 10:01 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez wrote:
>
>> I think that naming th
On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara
wrote:
> Larry,
>
> > Anthony, can you expand here at all about the practical benefits of
> > strong-typing for variable passing for the compiler? That seems to be
> the
> > main point of contention: Whether or not there are real, practical
> bene
Hi all,
On Fri, Feb 20, 2015 at 12:14 AM, Trevor Suarez wrote:
> I think that naming the new parent exception something like "Throwable" or
> "Catchable" (as Nikita previously suggested) would be a bit more concise in
> meaning than "BaseException". You may not have even meant that name as a
> f
Hi Bishop,
On Wed, Feb 18, 2015 at 9:18 PM, Bishop Bettini wrote:
> THING 2: Hints are truthy callables
>
> function my_mixed($m) {
> return (null === $m || is_string($m));
> }
> function f(is_scalar $s, is_int $i, my_mixed $m) {};
>
>
This is interesting idea. I'm sure it will be much slowe
2015-02-20 2:36 GMT+01:00 Levi Morrison :
> int, integer
> bool, boolean
> true, false
> float, double
I guess we should add 'real' here as well, since we still have the
(real) type cast and is_() type check for consistency:
C:\dev\php-src>php -r "var_dump((real) 42, is_real(13.37));"
float(42)
b
Bishop,
Pardon me for saying so, but I don't think you're on to a huge scoop here.
Scalar type hints - of all the kinds we've been talking about here, be them
strict, weak or coercive - can be easily emulated with a couple of lines of
code, we all know that. It's been known for years that strict
Hello!
The PHP development team announces the immediate availability of PHP 5.6.6.
This release fixes several bugs and addresses CVE-2015-0235 and
CVE-2015-0273.
All PHP 5.6 users are encouraged to upgrade to this version.
For source downloads of PHP 5.6.6 please visit our
downloads page: http://
> De : Pierre Joye [mailto:pierre@gmail.com]
>
> Such as? Competition is good and my past experiences is that in cases
> like this one, it is nearly an utopia to think that the other party
> will actually try to reach your needs. So the only way to actually get
> a RFC representing what you wan
On Thu, Feb 19, 2015 at 5:36 PM, Levi Morrison wrote:
> I would like to discuss a small RFC for reserving more types in PHP 7:
> https://wiki.php.net/rfc/reserve_more_types_in_php_7
>
> Essentially it proposes to reserve:
>
> int, integer
> bool, boolean
> true, false
> float, double
> string
> nu
Hi Levi,
Just my opinion :
Add 'resource', 'object', 'scalar', 'mixed', 'numeric'
Remove 'double' (avoid this alias if we decide to encourage 'float' everywhere)
Not sure we'll use Boolean and integer but reserve also.
Hope 'null', 'true', and 'false' can technically be used as type hints. If
On Thu, Feb 19, 2015 at 6:13 PM, François Laupretre wrote:
>> De : Pádraic Brady [mailto:padraic.br...@gmail.com]
>>
>> As I understand it, Andrea left her RFC free to be reused, reopened
>> and derived without any specific limitation. It would therefore appear
>> that it would be possible for the
On Thu, Feb 19, 2015 at 1:40 PM, Adam Harvey wrote:
> Hi all,
>
> Those of you with long memories will remember that I proposed a
> Comparable interface way back in the pre-5.4 days, but withdrew it
> when it became obvious that there was no consensus for it as a feature
> and that a vote was like
>
> >> THING 1: Hints are just is_* wrappers
> >
> > Wrong. Only *strict* types are.
> >
> >> THING 2: Hints are truthy callables
> >>
> >> function my_mixed($m) {
> >> return (null === $m || is_string($m));
> >> }
> >> function f(is_scalar $s, is_int $i, my_mixed $m) {};
> >
> > Not sure I und
> De : Pádraic Brady [mailto:padraic.br...@gmail.com]
>
> As I understand it, Andrea left her RFC free to be reused, reopened
> and derived without any specific limitation. It would therefore appear
> that it would be possible for there to be 100 derived RFCs all owned
> by different people, i.e. n
Larry,
> Anthony, can you expand here at all about the practical benefits of
> strong-typing for variable passing for the compiler? That seems to be the
> main point of contention: Whether or not there are real, practical benefits
> to be had in the compiler of knowing that a call will be in "str
Sorry: Apparently hit some hotkey for send.
On Thu, Feb 19, 2015 at 6:35 PM, Levi Morrison wrote:
> Dear Internals,
>
> I would like to discuss a small RFC for reserving more types in PHP 7:
> https://wiki.php.net/rfc/reserve_more_types_in_php_7
>
> Essentially it proposes to reserve:
int, integ
Dear Internals,
I would like to discuss a small RFC for reserving more types in PHP 7:
https://wiki.php.net/rfc/reserve_more_types_in_php_7
Essentially it proposes to reserve:
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Larry,
Thanks for trying to sort this out. This is very valuable work.
> De : Larry Garfield [mailto:la...@garfieldtech.com]
>
> Anthony, can you expand here at all about the practical benefits of
> strong-typing for variable passing for the compiler?
I will let Anthony reply as the question
On 19 February 2015 at 23:07, Anthony Ferrara wrote:
> All,
>
> An interesting point was brought up related to block mode:
> https://twitter.com/drrotmos/status/568540722586107904
>
> Namely that generated file caches may need the ability to switch block
> mode on-and-off.
>
> I'm considering maki
Hi François,
On 19 February 2015 at 23:13, François Laupretre wrote:
> I never asked anyone to abandon his work. I just asked to respect the rules.
> What I told you first is that, while Sara did not resigned formally, I didn't
> see why you could publish derived concurrent work from the RFC sh
Hi Anthony,
I'll post a more elaborate message later, including what I *really* sent to
Sara, so that we can estimate how rude I was. I'll also explain the context.
But I need a little more time to write it (I know I'm always asking for time ;).
The replies below are just quick and dirty.
> De
All,
An interesting point was brought up related to block mode:
https://twitter.com/drrotmos/status/568540722586107904
Namely that generated file caches may need the ability to switch block
mode on-and-off.
I'm considering making the change to add that. If that happens,
declare must be the outer
Robert,
> you wrote: "aliases are removed (integer and boolean)"
> what about the aliases real and double?
They were never part of Andrea's proposal. So they were never accepted anyway.
> You wrote: "behaviour of weak type checks: float -> int *Only non-NaN floats
> between PHP_INT_MIN and PHP_
On 02/19/2015 04:13 AM, Zeev Suraski wrote:
-Original Message-
From: Larry Garfield [mailto:la...@garfieldtech.com]
Sent: Thursday, February 19, 2015 9:00 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Reviving scalar type hints
On 02/17/2015 01:30 PM, Zeev Suraski wrote:
Yes, I
>> But even here I would rather just take a function instead of requiring
>> it to be the instance of some interface:
>>
>> function sort($input, callable $comparator($a, $b): int) {
>> /* … */
>> }
>
> Fair, but the sorting case isn't the only one that matters,
> particularly with <=> now as p
I don't want to get into a lengthy debate (you have your opinion; I
have mine!), but to rebut a couple of specific points:
On 19 February 2015 at 14:19, Levi Morrison wrote:
> Another issue: it allows comparing an object to non-objects (even
> though the stated goal is only to compare two objects
> Those of you with long memories will remember that I proposed a
> Comparable interface way back in the pre-5.4 days, but withdrew it
> when it became obvious that there was no consensus for it as a feature
> and that a vote was likely to fail.
>
> RFC: https://wiki.php.net/rfc/comparable
> PR: ht
Hi all,
Those of you with long memories will remember that I proposed a
Comparable interface way back in the pre-5.4 days, but withdrew it
when it became obvious that there was no consensus for it as a feature
and that a vote was likely to fail.
RFC: https://wiki.php.net/rfc/comparable
PR: https:
On Thu, Feb 19, 2015 at 11:26 PM, Anthony Ferrara
wrote:
> Nikita (and all),
>
> > * Subclassing: Should there be more specific subclasses of
> EngineException
> > for particular errors?
>
> I think there's an important case to be made here. I don't think every
> error belongs having its own sub
Hi folks :)
I know everyone is already quite busy attempting to resolve scalar
types, assertions, etc. So let me add another RFC to your
pre-feature-freeze cognitive overload! This proposal allows the
specification of and access to Generator return expressions:
https://wiki.php.net/rfc/generator-
Stas,
>> I created a forked RFC. You can keep her as lead all you want, that
>> doesn't mean I can't move forward with my RFC.
>
> I think it would really be better to have a lot less "us vs them" and a
> bit more cooperative spirit here.
That ignores the mail that spawned this thread (and the on
Hi!
> So rather than go for the 70-75% consensus that we **know** we have,
How we magically know that? We have the (unfinished) vote, which has a
tiny bit over 66% for the proposal. Where 75% comes from?
> I created a forked RFC. You can keep her as lead all you want, that
> doesn't mean I can't
Nikita (and all),
> * Subclassing: Should there be more specific subclasses of EngineException
> for particular errors?
I think there's an important case to be made here. I don't think every
error belongs having its own subclass, but there are at least a few
cases where it may make sense. This l
There isn't legitimate technical justification for or against using custom
exceptions.
Since it's entirely based on preference, and the kind of utilitarian
argument you can make for their use,
it's acceptable that this is resolved as part of the vote.
It's not a huge deal.
Cheers
Joe
On Thu, Fe
On 19 בפבר׳ 2015, at 22:08, Anthony Ferrara wrote:
>
> Zeev,
>
> Based on Sara's clarification in this thread, I owe you a formal
> apology. I interpreted something she said incorrectly, which was then
> compounded by messages in private and on-list this morning. I then
> attributed both of you
Zeev,
Based on Sara's clarification in this thread, I owe you a formal
apology. I interpreted something she said incorrectly, which was then
compounded by messages in private and on-list this morning. I then
attributed both of you qualities and motives that have been proven
false.
For this, I am
On 19/02/15 18:16, Pierre Joye wrote:
> This is not the point of this discussion. What you referto has to be
> done for anything PHP uses, every library, every extension or services
> (http or other).
Now read the rest of what I wrote ...
Where ever validated data comes from ... it does not need a
Nikita Nefedov wrote:
> 2015-02-19 6:44 GMT+04:00 Rasmus Lerdorf :
>>
>> I think it will be difficult to find a separator character that doesn't
>> make a mess of the grammar.
>
> Why not space? It's certainly possible (I just checked) and it would look
> clear I guess:
>
> my_func(1 999 999)
On Thu, Feb 19, 2015 at 10:02 AM, Lester Caine wrote:
> While typing this I did think to just scrap what I was writing, but I
> think it is relevant if only if someone can explain why I am wrong?
>
> On 19/02/15 17:06, Anthony Ferrara wrote:
With strictly typed $a and $b, the expression drops
While typing this I did think to just scrap what I was writing, but I
think it is relevant if only if someone can explain why I am wrong?
On 19/02/15 17:06, Anthony Ferrara wrote:
>>> With strictly typed $a and $b, the expression drops to 1 possible
>>> >> permutation. And you can detect if it's a
Hi Patrick,
I understand but we cannot include casting rules in the scope. And, while
attractive, I think ZPP and casting cannot share the same ruleset, at least as
long as casting is defined as aimed to being as permissive as possible.
François
De : Patrick ALLAERT [mailto:patrickall
On Thu, Feb 19, 2015 at 9:13 AM, Leigh wrote:
> On 19 February 2015 at 15:45, Pierre Joye wrote:
>> Still, no announce for a discussion about this specific RFC. And
>> really, the content of the RFC is almost empty, pointing to the ML
>> archive is really not the right way :)
>
> There was an RFC
Hi!
> At the function border, yes. But not beyond that.
Not sure what you mean here. If the value is identified as int, it
remains int. How strict typing would change that?
> Sort-of correct. We don't know if A is true, but we know what
> conditions need to exist for A->B to be true. We know tha
On Thu, Feb 19, 2015 at 5:24 AM, Anthony Ferrara wrote:
> On Thu, Feb 19, 2015 at 6:58 AM, François Laupretre wrote:
>> As long as she does not officially gives up (posting to the list), I'll keep
>> considering Sara still has the lead on scalar type hinting. If she
>> officially gives up, I'll
On 19 February 2015 at 15:45, Pierre Joye wrote:
> Still, no announce for a discussion about this specific RFC. And
> really, the content of the RFC is almost empty, pointing to the ML
> archive is really not the right way :)
There was an RFC announce thread 3 days ago. I agree 3 days is a short
Stas,
>> The reason is, with strict typing you only need to deal with 8
>> possible states for every variable (int, float, bool, resource, array,
>> object, callable, null and string). And many of those states you can
>> eliminate based on context (you know an argument passed to an int
>> declared
On 19/02/15 12:47, François Laupretre wrote:
> I didn't add restrictions specific to number representation in the draft
> ruleset yet, becausen while I think that's an important point, I didn't have
> time to study it in depth.
>
> I know you're an expert on this as you continuously (rightly) ra
I am not familiar with the implementation details but from my perspective
this would be a nice improvement. I have had a difficult time debugging PHP
fatal errors over the years and I think this kind of change would help
improve that.
On Mon, Oct 6, 2014 at 4:53 PM, Nikita Popov wrote:
> Hi inte
Hi!
> Based on the no reasons that people presented, and some back-of-envelope math.
That is not "knowing", much less "**knowing**". That is a guess based on
an estimate and set of assumptions, some of which very well may be wrong
(such as, people can have more than one reason to vote no).
> The
On 19 February 2015 at 16:25, Dmitry Stogov wrote:
>
> we are tying to
> do it with minimal breaks for our users. If we may keep compatibility, we
> would prefer to keep it,
Yeah - you still haven't said why choosing to extend exception rather
than using an interface has fewer BC problems.
> We
On Thu, Feb 19, 2015 at 7:06 PM, Dan Ackroyd wrote:
> On 19 February 2015 at 15:46, Dmitry Stogov wrote:
> > Exception declares protected properties that may be used in child classes
> > directly.
> > This is not possible with interface.
>
> So, you're saying it's easier to implement?
>
> That i
On Thu, Feb 19, 2015 at 8:21 AM, Lester Caine wrote:
> On 19/02/15 12:52, Zeev Suraski wrote:
>>> Now that all made sense!
>>> >
>>> > My only grey area is 'allowing sensible ones' where the size is an
>>> > integral part
>>> > of what is 'sensible' ... the one where conventional strict typing use
Arvids,
> I meant it in a way that no other RFC has failed so many times or had so
> much misunderstanding or divide.
No scalar type proposal has made it through a vote. So none of them
have technically failed (all except the current one were withdrawn).
> Sometimes it is required to ditch the p
On 19/02/15 12:52, Zeev Suraski wrote:
>> Now that all made sense!
>> >
>> > My only grey area is 'allowing sensible ones' where the size is an
>> > integral part
>> > of what is 'sensible' ... the one where conventional strict typing uses a
>> > type
>> > of the right size?
> I think the guiding p
Hey Anthony,
> -Ursprüngliche Nachricht-
> Von: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Gesendet: Mittwoch, 18. Februar 2015 21:45
> An: internals@lists.php.net
> Betreff: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
>
> Dear Internals,
>
> Since the resignation of Andrea
Stas,
On Thu, Feb 19, 2015 at 9:32 AM, Stanislav Malyshev wrote:
> Hi!
>
>> So rather than go for the 70-75% consensus that we **know** we have,
>
> How we magically know that? We have the (unfinished) vote, which has a
> tiny bit over 66% for the proposal. Where 75% comes from?
Based on the no
On Thu, Feb 19, 2015 at 7:45 AM, Pierre Joye wrote:
> On Thu, Feb 19, 2015 at 7:16 AM, Dmitry Stogov wrote:
>>
>>
>> On Thu, Feb 19, 2015 at 6:00 PM, Pierre Joye wrote:
>>>
>>> On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins
>>> wrote:
>>> > Morning internals,
>>> >
>>> > The expectations RFC
On 19/02/15 15:21, Zeev Suraski wrote:
> Focusing on my email to Sara (and several others), there is NOTHING, nothing
> wrong with a bit of private communications trying to gauge support,
> opposition, gaps and sort out differences before going for a public
> discussion.
My original comment was on
On 19 February 2015 at 15:46, Dmitry Stogov wrote:
> Exception declares protected properties that may be used in child classes
> directly.
> This is not possible with interface.
So, you're saying it's easier to implement?
That isn't a fantastic way of making a language design decision.
cheers
D
2015-02-19 17:41 GMT+02:00 Anthony Ferrara :
> Arvids,
>
> > I meant it in a way that no other RFC has failed so many times or had so
> > much misunderstanding or divide.
>
> No scalar type proposal has made it through a vote. So none of them
> have technically failed (all except the current one w
Exception declares protected properties that may be used in child classes
directly.
This is not possible with interface.
Thanks. Dmitry.
On Thu, Feb 19, 2015 at 6:31 PM, Dan Ackroyd wrote:
> On 19 February 2015 at 09:54, Dmitry Stogov wrote:
>
> > I think we may introduce the following hierarc
On Thu, Feb 19, 2015 at 7:16 AM, Dmitry Stogov wrote:
>
>
> On Thu, Feb 19, 2015 at 6:00 PM, Pierre Joye wrote:
>>
>> On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins
>> wrote:
>> > Morning internals,
>> >
>> > The expectations RFC is now in voting phase:
>> > https://wiki.php.net/rfc/expectatio
On Thu, Feb 19, 2015 at 7:21 AM, Zeev Suraski wrote:
>> -Original Message-
>> From: Pierre Joye [mailto:pierre@gmail.com]
>> Sent: Thursday, February 19, 2015 4:52 PM
>> To: Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
>
Hello!
The PHP development team announces the immediate availability of PHP
5.4.38. Seven security-related bugs were fixed in this release,
including CVE-2015-0273 and mitigation for CVE-2015-0235. All PHP 5.4
users are encouraged to upgrade to this version.
For source downloads of PHP 5.4.38 ple
On 19 February 2015 at 09:54, Dmitry Stogov wrote:
> I think we may introduce the following hierarchy
> the existing code that caught Exception is going to be unaffected.
We could do that. But it's not obviously correct, and ought to be
justified as to why it would be the correct thing to do.
T
On Thu, Feb 19, 2015 at 5:47 PM, Markus Fischer wrote:
> Hi,
>
> On 19.02.15 10:09, Joe Watkins wrote:
> > Morning internals,
> >
> > The expectations RFC is now in voting phase:
> > https://wiki.php.net/rfc/expectations#vote
>
> - I somehow miss information what the exact differences are to
On Thu, Feb 19, 2015 at 6:14 PM, Trevor Suarez wrote:
> I think that structure makes sense Dmitry.
>
> Though, just a bit on naming here (I know, its not a big deal, and naming
> is hard, haha):
>
> I think that naming the new parent exception something like "Throwable" or
> "Catchable" (as Nikit
2015-02-19 17:14 GMT+02:00 Pierre Joye :
> On Thu, Feb 19, 2015 at 7:11 AM, Arvids Godjuks
> wrote:
>
> > I think this starts to go the route of putting things into absolute.
> Ideal
> > things tend not to happen/work in the real world to the letter.
> >
> > Some things just don't work out by the
One question just popped up in my mind: what happens if there is a global
error handler in place that rethrows errors as exceptions. I heard such a
thing suggested pretty often. If not parse errors and other engine errors
get thrown as exceptions and are unhandled as such, and that error handler
th
On Thu, Feb 19, 2015 at 6:00 PM, Pierre Joye wrote:
> On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins
> wrote:
> > Morning internals,
> >
> > The expectations RFC is now in voting phase:
> > https://wiki.php.net/rfc/expectations#vote
>
> I totally miss the Expectation RFC announcement. Where th
I think that structure makes sense Dmitry.
Though, just a bit on naming here (I know, its not a big deal, and naming
is hard, haha):
I think that naming the new parent exception something like "Throwable" or
"Catchable" (as Nikita previously suggested) would be a bit more concise in
meaning than
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Thursday, February 19, 2015 4:52 PM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
> v0.5)
>
> On Thu, Feb 19, 2015 at 6:33 AM, Zeev Suraski wr
On Thu, Feb 19, 2015 at 7:11 AM, Arvids Godjuks
wrote:
> I think this starts to go the route of putting things into absolute. Ideal
> things tend not to happen/work in the real world to the letter.
>
> Some things just don't work out by themselves. The Type Hinting RFC's are an
> anomaly in the r
Hi Nikita,
I refactored your implementation: https://github.com/php/php-src/pull/1095
I introduced a class hierarchy to minimize effect on existing code.
cacth (Exception $e) won't catch new types of exceptions.
BaseException (abstarct)
+- EngineException
+- ParaseException
+- Exception
2015-02-19 16:51 GMT+02:00 Pierre Joye :
> On Thu, Feb 19, 2015 at 6:33 AM, Zeev Suraski wrote:
> >> -Original Message-
> >> From: Pierre Joye [mailto:pierre@gmail.com]
> >> Sent: Thursday, February 19, 2015 4:09 PM
> >> To: Zeev Suraski
> >> Cc: Anthony Ferrara; PHP internals
> >> Su
On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins wrote:
> Morning internals,
>
> The expectations RFC is now in voting phase:
> https://wiki.php.net/rfc/expectations#vote
I totally miss the Expectation RFC announcement. Where the RFC was
actually proposed for discussions.
I have been following u
On Thu, Feb 19, 2015 at 6:33 AM, Zeev Suraski wrote:
>> -Original Message-
>> From: Pierre Joye [mailto:pierre@gmail.com]
>> Sent: Thursday, February 19, 2015 4:09 PM
>> To: Zeev Suraski
>> Cc: Anthony Ferrara; PHP internals
>> Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Ty
Hi,
On 19.02.15 10:09, Joe Watkins wrote:
> Morning internals,
>
> The expectations RFC is now in voting phase:
> https://wiki.php.net/rfc/expectations#vote
- I somehow miss information what the exact differences are to the
current implementation, to better judge the impact.
- how does zend
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Thursday, February 19, 2015 4:24 PM
> To: Zeev Suraski
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
> v0.5)
>
> Zeev,
>
> This topic has been discus
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Thursday, February 19, 2015 4:09 PM
> To: Zeev Suraski
> Cc: Anthony Ferrara; PHP internals
> Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
> v0.5)
>
> We have seen off list discussion
Hi!
> So rather than go for the 70-75% consensus that we **know** we have,
How we magically know that? We have the (unfinished) vote, which has a
tiny bit over 66% for the proposal. Where 75% comes from?
> Saying a problem doesn't exist doesn't make it go away.
Except if it really doesn't exist
Zeev,
>> Then that's great! But let's find that out by voting rather than guessing,
>> and
>> rather than politicking. Let's let two competing proposals go head to
>> head.
>
> I'd rather find out by first discussing the alternative, rather than just
> moving ahead to a revote - especially a revot
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Thursday, February 19, 2015 4:04 PM
> To: Zeev Suraski
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
> v0.5)
>
> Zeev,
>
> That was a quote directly
On Thu, Feb 19, 2015 at 5:52 AM, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Thursday, February 19, 2015 3:24 PM
>> To: franc...@php.net
>> Cc: Lester Caine; internals@lists.php.net
>> Subject: [PHP-DEV] Using Other Channels (was
Hello Anthony,
Am 19.02.2015 um 14:01 schrieb Anthony Ferrara:
> I believe that RFCs should be opinionated. I dislike the recent trend
> around having a lot of voting options as it only complicates things
> for the voter.
I just thought giving a vote on how to enable strict mode would enable a
fe
Zeev,
On Thu, Feb 19, 2015 at 8:52 AM, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Thursday, February 19, 2015 3:24 PM
>> To: franc...@php.net
>> Cc: Lester Caine; internals@lists.php.net
>> Subject: [PHP-DEV] Using Other Channe
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Thursday, February 19, 2015 3:24 PM
> To: franc...@php.net
> Cc: Lester Caine; internals@lists.php.net
> Subject: [PHP-DEV] Using Other Channels (was Scalar Type Declarations
> v0.5)
>
> Let me quote something
2015-02-19 12:26 GMT+01:00 François Laupretre :
> Hi Patrick,
>
> I know you didn’t decide it alone, but the right solution, IMO, would have
> been to E_DEPRECATE nonsense conversions. That’s what we are currently doing
> for ZPP conversions (https://wiki.php.net/rfc/zpp-conversion-rules). I also
>
On 19/02/15 13:16, Nikita Nefedov wrote:
>
> Why not space? It's certainly possible (I just checked) and it would look
> clear I guess:
>
> my_func(1 999 999);
>
Yes, but what if I just missed one or two commas there? ;)
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Maili
Rasmus Lerdorf wrote:
> On 02/18/2015 11:21 PM, Rick Widmer wrote:
>
>> how about:
>>
>> my_func( '1,000.04' ); //if you want to use separators there.
>
> The problem with that is that the world is split. The other half, or
> actually more than half, would write that as '1.000,04'. There is no
Francois
On Thu, Feb 19, 2015 at 6:58 AM, François Laupretre wrote:
>> De : Lester Caine [mailto:les...@lsces.co.uk]
>>
>> On 19/02/15 04:44, Dennis Birkholz wrote:
>> > I just saw the reddit where you mention that v0.4 is practically
>> > abandoned now, so I will just renounce my previous mail!
Hi,
I drafted an RFC to continue output buffering despite an aborted
connection was detected. The title might well be a bit misleading, so
please read the RFC before judgement.
https://wiki.php.net/rfc/continue_ob
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To un
Dennis,
> Will you consider to let the people vote on how to enable strict mode
> like discussed in the v0.4 discussion? Like this here from the "Reviving
> scalar type hints" thread?
I believe that RFCs should be opinionated. I dislike the recent trend
around having a lot of voting options as it
> -Original Message-
> From: Lester Caine [mailto:les...@lsces.co.uk]
> Sent: Thursday, February 19, 2015 12:24 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Reviving scalar type hints
>
> On 19/02/15 09:13, Zeev Suraski wrote:
> > Obviously, I think 'weak' campers have a lot to
Francois and Lester (and all),
Please keep this thread on-topic. It should be for technical
discussions around this RFC only. If you have something non-technical
to discuss, please start a new topic.
Thanks
Anthony
On Thu, Feb 19, 2015 at 6:58 AM, François Laupretre wrote:
>> De : Lester Caine
Hi Lester,
I didn't add restrictions specific to number representation in the draft
ruleset yet, becausen while I think that's an important point, I didn't have
time to study it in depth.
I know you're an expert on this as you continuously (rightly) raised the point.
So, can you elaborate on t
Le Wed Feb 18 2015 at 19:10:08, François Laupretre a
écrit :
> > De : Patrick ALLAERT [mailto:patrickalla...@php.net]
> >
> > The biggest advantage, IMHO, is that you get the exact same result
> whether
> > you do:
> >
> > foo((int) $value);
> >
> > or:
> >
> > foo($value);
> >
> > ... wh
1 - 100 of 118 matches
Mail list logo
