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 and
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
Dennis,
On Sun, Mar 15, 2015 at 5:39 PM, Dennis Birkholz den...@birkholz.biz 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
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 together
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
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 m...@deroetzi.de 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
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
All,
On Wed, Mar 11, 2015 at 11:52 AM, Dan Ackroyd dan...@basereality.com 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
Zeev,
On Wed, Mar 11, 2015 at 4:50 PM, Zeev Suraski z...@zend.com 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
Subject: RE: [PHP-DEV] RE: [VOTE][RFC
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 approach tries
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
Dan,
On Tue, Mar 10, 2015 at 11:45 AM, Dan Ackroyd dan...@basereality.com wrote:
On 10 March 2015 at 15:02, Anthony Ferrara ircmax...@gmail.com 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
Lee,
On Fri, Mar 6, 2015 at 7:06 AM, Lee Davis leedavi...@gmail.com 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
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 -
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 as long as
Zeev,
On Tue, Mar 3, 2015 at 10:57 AM, Zeev Suraski z...@zend.com 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] Re: Zend JIT Open Sourced
Zeev,
On Tue
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 runtime.
I
Zeev,
On Tue, Mar 3, 2015 at 11:32 AM, Zeev Suraski z...@zend.com 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
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 dmitry
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)
That
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 is
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() is the
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
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
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 adopted for some
Zeev,
On Fri, Feb 27, 2015 at 3:36 PM, Zeev Suraski z...@zend.com 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
Subject: Re: [PHP-DEV] Re: Zend
Leigh and all,
On Thu, Feb 26, 2015 at 11:12 AM, Leigh lei...@gmail.com wrote:
On 26 February 2015 at 15:37, Tom Worster f...@thefsb.org wrote:
On 2/26/15, 3:48 AM, Stanislav Malyshev smalys...@gmail.com wrote:
The custom is that the first word names the function group (yes, I know
old
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
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).
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 every line
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.
Realistically,
Dmitry
On Wed, Feb 25, 2015 at 10:20 AM, Dmitry Stogov dmi...@zend.com wrote:
On Wed, Feb 25, 2015 at 6:06 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Dmitry:
On Wed, Feb 25, 2015 at 7:55 AM, Dmitry Stogov dmi...@zend.com wrote:
On Wed, Feb 25, 2015 at 2:42 PM, Niktia Nefedov inefe
Dmitry:
On Wed, Feb 25, 2015 at 7:55 AM, Dmitry Stogov dmi...@zend.com wrote:
On Wed, Feb 25, 2015 at 2:42 PM, Niktia Nefedov inefe...@gmail.com wrote:
On Wed, 25 Feb 2015 16:30:32 +0400, Dmitry Stogov dmi...@zend.com wrote:
anyone may tell, what this will print without running :)
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;
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 to
Dmitry,
On Wed, Feb 25, 2015 at 7:19 AM, Dmitry Stogov dmi...@zend.com 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
Dmitry,
On Wed, Feb 25, 2015 at 10:13 AM, Dmitry Stogov dmi...@zend.com wrote:
On Wed, Feb 25, 2015 at 6:03 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Dmitry,
On Wed, Feb 25, 2015 at 7:19 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Anthony,
Few notes:
- first of all
Tom
On Wed, Feb 25, 2015 at 6:21 PM, Tom Worster f...@thefsb.org 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,
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 stream of 0-9 integer
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 rather prefer
Padraic,
On Tue, Feb 24, 2015 at 4:17 PM, Pádraic Brady padraic.br...@gmail.com wrote:
Hi
On 24 February 2015 at 20:04, Anthony Ferrara ircmax...@gmail.com wrote:
If random_bytes() is harder than uniqid(), it's a non-starter.
Technically, it will be harder than uniqid() if producing
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 integer
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 that is
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 faster
Robert,
On Mon, Feb 23, 2015 at 3:27 AM, Robert Stoll p...@tutteli.ch 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
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 problem
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
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 values
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
Zeev,
On Mon, Feb 23, 2015 at 5:53 PM, Zeev Suraski z...@zend.com 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
Zeev,
On Sun, Feb 22, 2015 at 1:37 PM, Zeev Suraski z...@zend.com 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
Subject: Re: [PHP-DEV] Coercive
: Anthony Ferrara ircmax...@gmail.com, Dmitry Stogov dmi...@zend.com
On Sun Feb 22 2015 at 14:23:58 Zeev Suraski z...@zend.com wrote:
There have been several attempts:
for JS: http://users-cs.au.dk/simonhj/tajs2009.pdf
or similar techniques applied to PHP, quite outdated though:
https
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 would help.
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 type hints.
Stas,
On Sun, Feb 22, 2015 at 6:47 PM, Stanislav Malyshev smalys...@gmail.com 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
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.
2. It fails
Stas,
On Sun, Feb 22, 2015 at 8:35 PM, Stanislav Malyshev smalys...@gmail.com 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
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 changes
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. That
Ze'ev,
On Sun, Feb 22, 2015 at 6:57 PM, Zeev Suraski z...@zend.com 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-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar
Zeev,
So the code after the fix would look like this:
?php declare(strict_types=1);
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);
}
?
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 something where
Zeev,
On Sat, Feb 21, 2015 at 5:02 PM, Zeev Suraski z...@zend.com 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-DEV] Coercive Scalar Type Hints RFC
Zeev
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
Francois,
On Fri, Feb 20, 2015 at 8:14 PM, François Laupretre franc...@php.net 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
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
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 ircmax...@gmail.com wrote:
All,
An interesting point was brought up related to block mode
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):
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
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
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 their
Dmitry
On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye pierre@gmail.com wrote:
hi Dmitry,
On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara ircmax
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
Larry,
On Fri, Feb 20, 2015 at 6:31 PM, Larry Garfield la...@garfieldtech.com 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 (whether to
bypass
Robert,
On Fri, Feb 20, 2015 at 2:48 PM, Robert Stoll p...@tutteli.ch 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
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
Zeev,
On Fri, Feb 20, 2015 at 10:24 AM, Zeev Suraski z...@zend.com wrote:
On 20 בפבר׳ 2015, at 16:55, Anthony Ferrara ircmax...@gmail.com wrote:
verification and static analysis aren't enough?
Anthony,
While IMHO they're not enough to warrant substantial deviation from PHP's
behavior
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 Engine gets
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 ircmax...@gmail.com wrote:
Rasmus,
To be perfectly transparent here though, you should mention
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, in
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
be rectified before too long.
Thanks,
Anthony
On Thu, Feb 19, 2015 at 9:11 AM, Zeev Suraski z...@zend.com wrote:
-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
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 one I got
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
Zeev,
On Thu, Feb 19, 2015 at 8:52 AM, Zeev Suraski z...@zend.com 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
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 franc...@php.net wrote:
De
Francois
On Thu, Feb 19, 2015 at 6:58 AM, François Laupretre franc...@php.net 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
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 revote that was
Stas,
On Thu, Feb 19, 2015 at 9:32 AM, Stanislav Malyshev smalys...@gmail.com 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?
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
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
(); // compile error
This behaves consistent with namespace block-mode today (though the
strict type declaration would be required to be outside the namespace
block).
I'm considering adding it, as it's a valid use-case. What do you think?
Thanks
Anthony
On Wed, Feb 18, 2015 at 3:44 PM, Anthony
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_INT_MAX
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 strict
Leigh,
Internal Functions Like ceil() Return Unexpected Types
My opinion is that functions should return sane types for their
intended purpose, and functions that do not should be fixed.
I agree 100%. I just think that's outside the scope of this proposal.
Static Analysis Is Possible With
Dear Internals,
Since the resignation of Andrea, the mixed-mode type hint (called
declaration in the proposal) proposal has been left abandoned.
Considering that the ending votes were 67/34 (66.3%) with several
no-votes being only due to reasonably minor issues with the proposal,
I would like to
Albert,
On Wed, Feb 18, 2015 at 5:21 PM, Albert Casademont Filella
albertcasadem...@gmail.com wrote:
Hi Anthony!
Thanks for bringing this up again. I am asking you the same I asked Andrea 2
weeks ago on Twitter: make it a triple option vote please. She didn't want
to do it, hope you do! This
Christoph,
On Wed, Feb 18, 2015 at 6:09 PM, Christoph Becker cmbecke...@gmx.de 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 behavior of ints resulting
Zeev et al,
2. It is not not about being lossless or not. People expect bool - int to
be
disabled, for example, and it is not lossless.
3. It is more a question of finding a consensus about conversions which
don't
make sense, and disabling them. Examples include bool conversion to any
Dmitry,
On Mon, Feb 16, 2015 at 9:12 AM, Dmitry Stogov dmi...@zend.com wrote:
The type checks in PHP7 is quite cheap (2-3 CPU instructions). Strict or
weak check doesn't make any difference for fast path (the same 2-3
instructions). The slow patch for weak checks is going to be a bit more
101 - 200 of 602 matches
Mail list logo
