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
Zeev,
> There's nothing political about this and I do wish you stop portraying it as
> such. Instead of welcoming my proposal to get behind your (IMHO bad)
> proposal, you're calling me political. Can you commit to support the Basic
> STH proposal if it gains something that's close to majority a
Zeev,
On Sun, Mar 15, 2015 at 3:07 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Pádraic Brady [mailto:padraic.br...@gmail.com]
>> Sent: Sunday, March 15, 2015 9:00 PM
>> To: Zeev Suraski
>> Cc: Bob Weinand; PHP Internals
>> Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
Zeev,
>> Thus, I deny your request and strongly urge you to *not* fork my RFC.
> That
>> would be sabotaging of Anthony's and my RFC.
>> I won't tolerate that.
>
> Anthony welcomed competing RFCs, and in fact proposed it. I don't see how
> it would be sabotaging your RFC - when in fact it gives i
Zeev,
>> Zeev, allow me to understand how this goes. Bob's discussions on the RFC
>> started 2 days ago. Based on the current rules, the RFC can only go to
>> vote
>> after 2 weeks. That means in 12 days starting now.
>>
>> So we are either violating the RFC rules by pushing the vote tomorrow or
>
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 to pull some stats.
The following voters never voted before the dual-mode RFC went up:
dom - no
eliw - no
kguest - yes
kk - no
nohn - no
oliver - yes
Arvids,
> That declare thing with the removal of block-aware declare(){} kills one of
> the fundamental optimizations you can do for large PHP projects - compacting
> most used files into one single big file and caching it. And you never had
> to care what the files are - just splice it all toget
All,
There's something that I think needs to be said about the now 3 scalar
type proposals. Please bear with me, there's a lot to say here. I'll
try to keep it as brief as I can.
I've been working off-and-on on scalar types for over 3 years. I've
officially proposed 3 proposals and have discussed
Welcome!!!
I'd love to hear more about your thesis if you can share!
Anthony
On Tue, Mar 10, 2015 at 6:56 AM, Johannes Ott wrote:
> Hi,
>
> sorry I did the wrong order, starting to discuss already without
> introducing me first:
>
> My name is Johannes Ott. I am 31 years old. I'm developing wit
Zeev,
On Wed, Mar 11, 2015 at 4:50 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Derick Rethans [mailto:der...@php.net]
>> Sent: Wednesday, March 11, 2015 10:37 PM
>> To: Zeev Suraski
>> Cc: Anthony Ferrara; internals@lists.php.net
>> S
Zeev,
>> You also stated above that false->bool is not supported (I'm guessing
> you
>> meant float->bool). So users would be able to pass "4.3" to a bool
> typehint,
>> but not 4.3? This behavior seems very arbitrary and confusing.
>
> It may be confusing, but only academically so. Again, this a
All,
On Wed, Mar 11, 2015 at 11:52 AM, Dan Ackroyd wrote:
> Voting no due to:
>
> i) Having conversion rules be difference in userland to internal functions.
>
> You list 'Single Mode' as a benefit of this RFC, but it's only single
> mode if you gloss over this difference. This is a massive cogni
Zeev,
Considering that there has not been any discussion of your final
proposal (since the last change), I think putting it to vote prior to
having the ability to test or discuss is extremely problematic.
Especially considering every time we tried to test the proposal or
discuss it before you said
Patrick,
My viewpoint is that options in an RFC are dangerous. I would much
rather have a single RFC, with a single vote (yes/no). I think we
should be discouraging the options as much as possible.
The reason is simple: an RFC should be an encapsulated idea, not a
menu of options. The author shou
Dan,
On Tue, Mar 10, 2015 at 11:45 AM, Dan Ackroyd wrote:
> On 10 March 2015 at 15:02, Anthony Ferrara wrote:
>>
>> Can we please come down to a single RFC, with a single vote yes/no?
>> It's easier to understand, easier to manage and has less possibility
>> of
Lee,
On Fri, Mar 6, 2015 at 7:06 AM, Lee Davis wrote:
>
> Hi Anthony.
>
>This issue that has plagued me in the past, specifically with the use of
> traits:
>
> Error: http://3v4l.org/VFguK
> OK: http://3v4l.org/73b86
>
> Although when combined with opcache does causes very confusing beha
All,
Currently, use has a few error cases that are rather fragile. For example:
namespace Biz {
class Bar {};
}
namespace Foo {
use Biz\Bar;
$a = new Bar;
var_dump($a);
}
namespace Foo {
class Bar {};
}
http://3v4l.org/IPTiQ
That works 100% of the time, on 5.3.0 -> present
Dmitry,
>> So, let's put that to the test, shall we. I compiled and ran the "JIT"
>> compiler (can we please stop calling it that, it's not).
>
>
> This is JIT!
My apologies. I interpreted your reply to an earlier email that you
were doing all of the code generation at compile time, not at runtim
Zeev,
On Tue, Mar 3, 2015 at 11:32 AM, Zeev Suraski wrote:
>> It wins on uneven ground.
>
> Without the output buffering code it's a LOT more uneven, as the PHP version
> is flushing every byte - approx. 6,000 such flushes.
Then the benchmark should suffer because of that. You're testing the
ful
Zeev,
On Tue, Mar 3, 2015 at 10:57 AM, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Tuesday, March 03, 2015 5:44 PM
>> To: Zeev Suraski
>> Cc: PHP Internals
>> Subject: Re: [PHP-DEV]
Zeev,
>> I agree with that as well, just Anthony gave a different opinion which
>> seems
>> right as well.
>
> I think that if we ever have optimization passes that are prohibitively
> expensive to run interactively (most probably around JIT) we'll definitely
> need new strategies for them. But a
Zeev,
On Tue, Mar 3, 2015 at 8:05 AM, Zeev Suraski wrote:
>> So I do apologize to the person. I don't to the code.
>
> I wanted to verify whether my gut was correct (minimal amount of output, and
> stdout is in fact buffered - output shouldn't move the needle) and asked
> Dmitry to rerun the C te
Julien,
> Bob's code optimizes things by adding a new OPCode.
> This is different from compiler optimizations.
>
> Compiler optimizations are about changing native, supported OPCode
> structures to other native supported OPCode structure, but that will run
> faster at runtime.
>
> I agree with dm
Zeev,
On Fri, Feb 27, 2015 at 3:36 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Friday, February 27, 2015 10:21 PM
>> To: Dmitry Stogov
>> Cc: Zeev Suraski; Jordi Boggiano; PHP Internals
>
Dmitry,
> Sneaky sneaky. Also completely fake.
It's been brought to my attention that some people have taken what I
said completely out of context and insinuated it as a direct insult to
you. I assure you that was not the intent (I called the benchmark
sneaky and fake, which it is).
So if you in
Dmitry,
>> That's not to say there's anything wrong with this approach, nor that
>> there isn't a ton we can learn from it. I think it's a fantastic
>> research effort and plan on digging through it myself. Thank you for
>> open sourcing it.
>
>
> Thanks for good words :)
>
> This work may be adop
Zeev,
>> Right now it compiles script (php file) at once.
>> So yes, our JIT uses some kind of AOT approach, but completely
>> transparently for the rest of PHP.
>
> Just to slightly further clarify - we don't compile the whole codebase at
> once, but we keep the existing semantics that every file
Dmitry,
> It's not a single request cycle. JIT integrated into opcache, it compiles
> php script(s) of first access and stores code in shared memory.
> On following requests precompiled code is executed directly from shared
> memory.
>
> - The first request may be extremely slow (few minutes)
Th
Cristian,
>> All those are due to a bug in substr(), that we see now only thanks to
>> proper type identification. There is no reason for substr() to ever return
>> a boolean. It really needs to be fix to always return a string.
>>
>> Damien
>
> It is not a bug. FALSE as a return value of substr()
Dmitry and Zend,
Thank you for sharing your code. I look forward to playing with it.
Perhaps after 7 stabilizes (and ships) you could write up your
thoughts around it? Why decisions were made and the findings that you
have?
Thanks again
Anthony
On Fri, Feb 27, 2015 at 7:10 AM, Dmitry Stogov w
Zeev,
>> We apparently have a different definition of "less". Your proposal
>> requires
>> you to worry about every type in every line of code that ever existed.
>> Yes,
>> there are fewer dangerous type change errors, but you need to look at
>> every
>> line of your application to find them.
>
>
Zeev,
>> With the current coercive proposal, you will still need to worry about the
>> types: https://wiki.php.net/rfc/coercive_sth#coercion_rules
>
> That's true, but a lot, lot less.
We apparently have a different definition of "less". Your proposal
requires you to worry about every type in eve
Mike,
One point of clarification:
> This is true, however, the types that you are receiving back form a
> multitude of data sources might be in a mixed format (databases for example
> often provide representation back as a string, non-json based web services
> provide mainly as a string, etc).
Leigh and all,
On Thu, Feb 26, 2015 at 11:12 AM, Leigh wrote:
> On 26 February 2015 at 15:37, Tom Worster wrote:
>> On 2/26/15, 3:48 AM, "Stanislav Malyshev" wrote:
>>
>>>The custom is that the first word names the function group (yes, I know
>>>old functions do not follow it, but this is new o
All,
I have opened voting on Scalar Type Declarations v0.5. Please cast your vote.
https://wiki.php.net/rfc/scalar_type_hints_v5#vote
The vote will remain open until March 13th, 2015 or until the date a
competing RFC closes voting, whichever is later.
Thanks
Anthony
--
PHP Internals - PHP Ru
Tom
On Wed, Feb 25, 2015 at 6:21 PM, Tom Worster wrote:
> Hi Leigh,
>
>>We're still discussing whether a userland (non-kernel userland)
>>implementation of arc4random is wise. We need to put some feelers out
>>and consult some experts on this,
>
> I wouldn't. As Thomas Patcek put it, quoting the
Tom,
On Wed, Feb 25, 2015 at 2:39 PM, Tom Worster wrote:
> I welcome the proposal for an easy-to-use PHP function for obtaining
> crypto-secure randomness. I have a number of comments and suggestions.
>
> I think the function name(s) should indicate that these functions are
> for getting crypto-s
Dmitry,
> But checks are performed not in the caller but in RECV opcode at called
> function.
> And in this function we don't know id it's going to be called only in strict
> mode or in weak as well.
Currently, yes. However, by the time we enter ZEND_DO_FCALL, we know
which function we're going t
Dmitry,
On Wed, Feb 25, 2015 at 10:13 AM, Dmitry Stogov wrote:
>
>
> On Wed, Feb 25, 2015 at 6:03 PM, Anthony Ferrara
> wrote:
>>
>> Dmitry,
>>
>> On Wed, Feb 25, 2015 at 7:19 AM, Dmitry Stogov wrote:
>> > Hi Anthony,
>> >
>> >
Dmitry
On Wed, Feb 25, 2015 at 10:20 AM, Dmitry Stogov wrote:
>
>
> On Wed, Feb 25, 2015 at 6:06 PM, Anthony Ferrara
> wrote:
>>
>> Dmitry:
>>
>> On Wed, Feb 25, 2015 at 7:55 AM, Dmitry Stogov wrote:
>> > On Wed, Feb 25, 2015 at 2:42 PM, Niktia N
Dmitry,
> The object on the call-site should remain to be an object (if it's not
> passed by reference), however the called function will receive a string.
> It works in PHP-5 and PHP-7. Nothing should be changed.
>
> $ sapi/cli/php -r 'class X {function __toString(){return "abc";}} $x=new X;
> va
Dmitry:
On Wed, Feb 25, 2015 at 7:55 AM, Dmitry Stogov wrote:
> On Wed, Feb 25, 2015 at 2:42 PM, Niktia Nefedov wrote:
>
>> On Wed, 25 Feb 2015 16:30:32 +0400, Dmitry Stogov wrote:
>>
>> anyone may tell, what this will print without running :)
>>>
>>> main.php
>>>
>>> >> declare(stric
Dmitry,
On Wed, Feb 25, 2015 at 7:19 AM, Dmitry Stogov wrote:
> Hi Anthony,
>
> Few notes:
>
> - first of all, it would be great to split the voting questions: 2/3 -
> implement scalar type hinting + 1/2 - in addition add strict type hinting as
I've mentioned this a few times, but I disagree wit
Padraic,
>>> Technically, it will be harder than uniqid() if producing strictly
>>> random bytes (if output needs to be printable/readable).
>>> That's not a "bad" thing obviously!
>>
>> Sure. But does that indicate the need for a "random_string()" function?
>
> It would be more random than a stre
Padraic,
On Tue, Feb 24, 2015 at 4:17 PM, Pádraic Brady wrote:
> Hi
>
> On 24 February 2015 at 20:04, Anthony Ferrara wrote:
>> If random_bytes() is harder than uniqid(), it's a non-starter.
>
> Technically, it will be harder than uniqid() if producing strictly
>
Pierre,
>> In fact I had planned for a future RFC where we allow
>> session.entropy_file to use using random_bytes(). So the "best" source
>> is chosen automatically. (If you think there are better sources not
>> covered by this patch, please let me know, I would like it to be
>> complete)
>
> I r
Zeev,
On Mon, Feb 23, 2015 at 5:53 PM, Zeev Suraski wrote:
> Anthony,
>
> Thanks for testing, but it's a bit premature to jump to conclusions.
>
> First, disabling phar is in the patch instructions at
> github.com/php/php-src/pull/1110 - it's a bug in phar that needs to be
> fixed. We'll address
Zeev,
> Secondly, for some reason you appear very opinionated that this will result
> in huge breakage, even though we don't yet have any evidence to suggest it'd
> be the case, at least not yet.
So I tried to compile the patch to get a real-world idea of the breaks.
The first thing, PHP's own p
Matt,
>> And what about other languages that have exactly this behavior? Such
>> as Go/Hack/Haskell/etc. Do you see casts everywhere? No. You see them
>> where it needs to be explicit. Otherwise, people just write using the
>> correct types.
>>
>> And it also hand-waves over the fact that the same
Matt,
> The big problem currently is that the engine behavior around casting can lead
> to
> data loss quickly. As has been demonstrated elsewhere:
>
> $value = (int) '100 dogs'; // 100 - non-numeric trailing values are
> trimmed
> $value = (int) 'dog100'; // 0- non-numeric value
Zeev,
As this is going in circles, this will be my last post here (it seems
we feel the same in this regards):
> Those were our results:
> PHPNG-JIT (JIT=on) 0.011 (25 times faster than php-7)
> gcc -O2 (4.9.2)0.013
> gcc -O0 (4.9.2)0.022
>
Robert,
> [Robert Stoll]
> Sure, "a" was just an example to illustrate the problem. I figured it would
> not be necessary to say that the value of $b can be completely unknown by the
> static analyser -> could come from user input, from a database, from
> unserialising code etc. (but probably t
Zeev,
>> Maybe I'm ignorant of something, but isn't the only way you can begin to
>> infer the type with real confidence is by having strict typed parameters ?
>
> Not at all. You can definitely infer lots of type information without any
> type hints, strict or weak. bench.php wouldn't be 25x fa
Zeev,
>> You're still doubling the number of CPU ops and adding at least one branch
>> at
>> runtime, but not a massive difference.
>
> To be honest, I missed an important part in the semantics of the sample
> code, the fact that the result of the division in bar() is sent to function
> with an i
Robert,
On Mon, Feb 23, 2015 at 3:27 AM, Robert Stoll wrote:
> Hey all,
>
> tl;dr
>
> Just one point which JIT/AOT people should consider when dealing with PHP.
> PHP is highly dynamic and there are enough use cases which makes it
> impossible for a static analyser to infer types accurately wit
Zeev,
> So the code after the fix would look like this:
> function foo(int $int): int {
> return $int + 1;
> }
>
> function bar(int $something): int {
> $x = (int) $something / 2; // (int) or whatever else makes it clear
> it's an int
> return foo($x);
> }
> ?>
>
> Let me explain how
Stas,
On Sun, Feb 22, 2015 at 8:35 PM, Stanislav Malyshev wrote:
> Hi!
>
>> The difference though is the journey. The static analyzer can reason
>> about far more code with strict types than it can without (due to the
>> limited number of possibilities presented at each call). So this
>> leaves t
Stas,
>> It is still a performance advantage, because since we know the types
>> are stable at compile time, we can generate far more optimized code
>> (no variant types, native function calls, etc).
>
> I don't see where it comes from. So far you said that your compiler
> would reject some code.
Zeev,
>> Partially.
>>
>> The static analysis and compilation would be pure AOT. So the errors would
>> be told to the user when they try to analyze the program, not run it.
>> Similar
>> to HHVM's hh_client.
>
> How about that then:
>
> 1. The developers runs a static analyzer on the program.
>
Zeev,
> I think we are indeed getting somewhere, I hope.
> If I understand correctly, effectively the flow you're talking about in your
> example is this:
>
> 1. The developers tries to run the program.
> 2. It fails because the static analyzer detects float being fed to an int.
> 3. The user chan
Ze'ev,
On Sun, Feb 22, 2015 at 6:57 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Monday, February 23, 2015 1:35 AM
>> To: Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP-DE
Stas,
On Sun, Feb 22, 2015 at 6:47 PM, Stanislav Malyshev wrote:
> Hi!
>
>> You can tell because you know the function foo expects an integer. So
>> you can infer that $x will have to have the type integer due to the
>> future requirement. Which means the expression "$something / 2" must
>> also
Adding in a thread that was started in private, but absolutely is
worth sharing with the group:
-- Forwarded message --
From: Etienne Kneuss
Date: Sun, Feb 22, 2015 at 8:42 AM
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
To: Zeev Suraski
Cc: Anthony Ferrara , Dmitry
Zeev,
>> And note that this can only work with strict types since you can do the
>> necessary type inference and reconstruction (both forward from a function
>> call, and backwards before it).
>
> Please do explain how strict type hints help you do inference that you
> couldn't do with dynamic typ
Stas,
>>> -- Can the code generated for a strict type hint can somehow be optimized
> significantly better than the code generated for a dynamic/coercive type
> hint.
>> And me, who wrote an AOT compiler that does **exactly** this, claim
>
> Sorry, did exactly what? Here a bit more explanation wou
Zeev,
On Sun, Feb 22, 2015 at 1:37 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Jefferson Gonzalez [mailto:jgm...@gmail.com]
>> Sent: Sunday, February 22, 2015 4:25 PM
>> To: Etienne Kneuss; Anthony Ferrara; Zeev Suraski
>> Cc: PHP internals
>
Zeev,
> > > Two more things regarding the competing RFC – it’s still alive, and
> > > being promoted for PHP 7.0; And while it doesn’t create a huge BC
> > > break, it allows developers to selectively create localized BC breaks,
> > > on a per file basis.
> >
> > No, it does not. A BC break is so
Zeev,
On Sat, Feb 21, 2015 at 5:02 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Saturday, February 21, 2015 10:08 PM
>> To: Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP
Zeev,
I won't nit-pick every point, but there are a few I think need to be clarified.
>> > Proponents of Dynamic STH bring up consistency with the rest of the
>> language, including some fundamental type-juggling aspects that have been
>> key tenets of PHP since its inception. Strict STH, in thei
Pierre,
> And finally, this RFC only proposes one solution, so competitive RFCs
> are still required to actually represent alternatives.
That is a good thing. it should only propose one solution. Making a
single RFC proposing two solutions would be a MASSIVE mistake IMHO as
these proposals are co
Zeev,
First off, thanks for putting forward a proposal. I look forward to a
patch that can be experimented with.
There are a few concerns that I have about the proposal however:
> Proponents of Strict STH cite numerous advantages, primarily around code
> safety/security. In their view, the conv
Francois,
> Adding this case to 'float' meaning 'int|float' and 'callable' resolving to
> 'string|array|object', are you sure it's worth the pain implementing and
> supporting a dual-mode mechanism, compared to the ruleset I am intending to
> propose (currently in draft): https://wiki.php.net/r
Francois,
> I sent you a copy of the messages I sent to Sara, asking for more details
> about what you consider as 'deplorable' in them. I also sent another message
> to get your opinion about the new ruleset I could propose. It seems you
> didn't have time to reply. Just hope you don't refuse
vior, but am holding
off on the implementation until the engine exceptions vote concludes
(if it fails, the behavior documented in the RFC would be
implemented).
Thanks
Anthony
On Fri, Feb 20, 2015 at 4:09 PM, Anthony Ferrara wrote:
> All,
>
>> An interesting point was brought up
Zeev,
> Anthony,
>
> Following Adam's analysis of the timeline, taking the more 'strict' (no pun
> intended!) interpretation of the timeline RFC, we still have until tomorrow
> to start the discussion and still target it for 7.0, no? Given the
> importance of this topic, I'd go for the more lax i
Francois,
On Fri, Feb 20, 2015 at 8:14 PM, François Laupretre wrote:
> Hi Anthony,
>
> I guess you would keep supporting __toString() ? So, you should probably
> consider 'string' as 'string|object'.
> Adding this case to 'float' meaning 'int|float' and 'callable' resolving to
> 'string|array|o
Larry,
On Fri, Feb 20, 2015 at 6:31 PM, Larry Garfield wrote:
> On 02/20/2015 06:28 PM, Anthony Ferrara wrote:
>>
>> Considering I'm not targetting 7 (I've updated the RFC to hint this), we
>> can choose what to do later depending on the exceptions result (wh
Robert,
On Fri, Feb 20, 2015 at 2:48 PM, Robert Stoll wrote:
> Hi Dmitry and Anthony,
>
> I was skimming through your conversation about JIT/AOT and that type hints
> would allow to optimise few things.
> I do not know if you are aware of the following but type hints can be passed
> by. Hence
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 mus
Point of clarification: it exists in the RFC already:
https://wiki.php.net/rfc/scalar_type_hints_v5#internal_functions_should_opt-in_to_typing
On Fri, Feb 20, 2015 at 2:06 PM, Anthony Ferrara wrote:
> Rasmus,
>
>> To be perfectly transparent here though, you should mention that your
Rasmus,
> To be perfectly transparent here though, you should mention that your
> proposed RFC goes well beyond the strict typing that is in Hack because
> in Hack the internal API is largely untyped while your proposal is to
> default the entire internal API to strict types in strict mode. Also,
Larry,
> Assume for a moment that:
>
> - we tighten up the default passing rules, such that "32" passed to an int
> works but "32 footsteps" errors (which I thing most are on board with doing)
> - we include a strict types mode as proposed, including the logical type
> widening cases
> - Zend En
Zeev,
On Fri, Feb 20, 2015 at 10:24 AM, Zeev Suraski wrote:
>
>> On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara wrote:
>>
>> verification and static analysis aren't enough?
>>
>
> Anthony,
>
> While IMHO they're not enough to warrant substa
Chris,
I'll edit in the proposal, but you can check the tests in the mean time:
https://github.com/ircmaxell/php-src/blob/c8590799622ddb801360664d08ac5d7f4fa342df/Zend/tests/typehints/scalar_strict_declaration_placement_002.phpt
https://github.com/ircmaxell/php-src/blob/c8590799622ddb801360664d08
Dmitry
On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov wrote:
>
>
> On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye wrote:
>>
>> hi Dmitry,
>>
>> On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov wrote:
>> > On Fri, Feb 20, 2015 at 4:57 AM, Ant
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
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_
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
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
an be rectified before too long.
Thanks,
Anthony
On Thu, Feb 19, 2015 at 9:11 AM, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Thursday, February 19, 2015 4:04 PM
>> To: Zeev Suraski
>> Cc: internals@lis
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
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
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
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
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
>
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!
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
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
Christoph,
On Wed, Feb 18, 2015 at 6:09 PM, Christoph Becker wrote:
> Anthony Ferrara wrote:
>
>> 3. int typed variables can resolve a parameter type of float So
>> calling requiresAFloat(10) will work even in strict mode.
>
> Have you considered the overflow behavio
101 - 200 of 616 matches
Mail list logo
