Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83804
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nEk6BhPYD9iE9B4V2CN1vSZXhJbSbh7z=s4XE911RquCg@mail.gmail.com>
References: <CAAyV7nGjdguX=4Nt0H=kYnwg8rZ1BkWf8duGZfzheOXXV61pqA@mail.gmail.com>
	<CAAyV7nE+JJPr4iRiFfJg74UVZ_c6HieOmpPQWe6zwnY==m7Zhw@mail.gmail.com>
	<CAAyV7nGOh7FgkbkPGwALmU4SDOs=LvkijAPJeNcG3qrMo7-z-Q@mail.gmail.com>
	<CAAyV7nFfzaw=M0En4_3Lt5MYQ7H+ePCzFOuM4wndehxJER7NXQ@mail.gmail.com>
	<CA+9eiLuuH7v4Vvf8iDzvh=vho9mdPUpvSVHwuP6+JdNVkqLS9A@mail.gmail.com>
	<CAAyV7nFV9VhC=5MTr+iXxJniLg1pcyLVbv7gZAFfPiYu1soh2A@mail.gmail.com>
	<CA+9eiLuhu1mxaFeuFbEk67Hdx1KxwzG287W7VghwH0kio250SQ@mail.gmail.com>
	<CAAyV7nEk6BhPYD9iE9B4V2CN1vSZXhJbSbh7z=s4XE911RquCg@mail.gmail.com>
Date: Wed, 25 Feb 2015 19:55:27 +0400
Message-ID: <CA+9eiLtgjVCe1hahAG+MvYQi_w-twp4Sv_vo37B03VLUfpX0Xw@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01628326fee76c050feba939
Subject: Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
From: dmitry@zend.com (Dmitry Stogov)

--089e01628326fee76c050feba939
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 25, 2015 at 6:47 PM, Anthony Ferrara <ircmaxell@gmail.com>
wrote:

> Dmitry,
>
>
> On Wed, Feb 25, 2015 at 10:13 AM, Dmitry Stogov <dmitry@zend.com> wrote:
> >
> >
> > On Wed, Feb 25, 2015 at 6:03 PM, Anthony Ferrara <ircmaxell@gmail.com>
> > wrote:
> >>
> >> Dmitry,
> >>
> >> On Wed, Feb 25, 2015 at 7:19 AM, Dmitry Stogov <dmitry@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 disagree with that concept. I
> >> believe RFCs should fully describe a feature and should be voted on in
> >> whole.
> >>
> >> Additionally, it presents a problem when it comes to voting. What if a
> >> person wants strict types. And it looks like it's overall going to
> >> pass, but that weak types is winning. What's the best way for them to
> >> vote? No. For the entire proposal.
> >
> >
> > It's also a reason why others may vote against the whole and we will get
> > nothing.
> >
> >>
> >>
> >> I'd rather keep the vote about one thing, and one thing only.
> >
> >
> > I got you. All or nothing :)
>
> Yes. Because you, Zeev and Francois are making a competing proposal.
> Which is the better way to decide, since then people can vote
> independently for a specific implementation, not a complex set of
> switches.
>
> So if both fail, then we don't see scalar type declarations. If one
> passes, we know what people want. If both pass, then we deal with that
> then.
>
> I even agreed to postpone the vote on this proposal so you could
> finish yours. So please stop trying to spread FUD here and play both
> sides of the game.
>

OK. It's going to be the last email.


>
> >> > you propose. I think, the concept of run-time declare() switch is not
> >> > designed well. It just affects VM and JITed code in negative way,
> >> > because in
> >> > each function we will have to handle both options
> >> >
> >> >
> https://github.com/ircmaxell/php-src/compare/scalar_type_hints_v5#diff-3054389ad750ce9a9f5895cd6d27800fR3762
> >> > and also set additional flag on each call
> >> >
> >> >
> https://github.com/ircmaxell/php-src/compare/scalar_type_hints_v5#diff-3054389ad750ce9a9f5895cd6d27800fR2802
> >>
> >> What negative way is that? It's a clearly defined switch, kept in a
> >> clearly defined place.
> >>
> >> And considering it's a purely compile time construct, I fail to see
> >> how it could possibly affect either the VM or JITed code in a negative
> >> way.
> >
> >
> > I post the links to the important changes above. Even JITed code will
> have
> > to implement these additional checks in run-time.
>
> The call is compiled at compile time. The call's strict mode is
> decided at compile time. So while the actual type checks happen at
> runtime, and the function binding happens at runtime, the actual
> switch happens at compile time.
>

Even Java don't always know the method it's going to call at compile-time.
PHP doesn't know it for sure.


>
> >> Heck, if we really wanted to, we could compile a separate
> >> ZEND_DO_FCALL opcode for strict types: ZEND_DO_STRICT_FCALL, which
> >> hard-codes the strict data.
> >
> >
> > It's not so simple, because you don't know the function at compile-time.
>
> You don't need to know the destination function to determine if it's
> going to be strict mode or not.
>

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.


>
> >> I think leaving the ability to create a class named "string" while at
> >> the same time removing the ability to type against it is not only
> >> weird, but definitely not something I think we should do (it's just
> >> way to inconsistent).
> >
> >
> > this is your opinion. I have another. I don't know opinion of others.
> > Why not to 50/50 voting. If you don't do it, may be I should do.
>
> I said it was my opinion.
>
> I also will not put it up to vote, because the proposal is a
> codification of my views for the way forward. I said I'd be open to
> discussing anything in the proposal. But ultimately it's a single
> proposal, not a menu of choices. Please stop asking me to add
> individual votes for every little detail. The only thing that
> accomplishes is making it infinitely harder for people to understand
> what they are voting on. Right now, it's an "all or nothing" vote.
> Which means that it's very easy for people to understand what they
> will get if it passes.
>


Thanks. Dmitry.


>
> >>
> >> "Break" is a loaded term.
> >
> >
> > OK. it's a BC break.
> > What is the reason for __toString() if it's not going to be called.
>
> It's absolutely not a BC break by any definition of the term that
> we've **ever** used here, nor in the community. It's 100% acceptable
> with semver. Heck, even Wikipedia's definition is consistent:
> http://en.wikipedia.org/wiki/Backward_compatibility
>
> You have to specifically opt-in to strict mode. Meaning that unless we
> make changes to the coercive mode, there is by definition no BC break.
>
> I expect you'll vote against the proposal either way, which is fine.
> But please stop spreading misinformation and using loaded terms
> improperly.
>
> As far as "what is the reason for __toString if it's not going to be
> called" I explained it right below where you quoted:
>
> > It's intentionally not calling __toString, because that's not only a
> > cast (like "5" -> int(5)), but it's a lossy cast (like 5.5 -> int(5)
> > or "5 apples" => int(5)).
>
> __toString will still work in weak mode for parameters, and you can
> still echo out the string just fine. But if you accept an object that
> implements __toString, you can't just pass it to strlen without
> explicitly converting it to a string first. Just like numbers. Just
> like all of the other conversions. Just like you can't pass a Foo
> instance to something expecting a Bar instance without an adapter in
> between.
>
> It'd be quite weird to reject int(5) for string, while accepting new
> FooHasToString();. So either we go full strict (hence the strict mode)
> or we don't (hence the weak mode). Here, we're giving the author the
> choice.
>
> Anthony
>

--089e01628326fee76c050feba939--