Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83802
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLuhu1mxaFeuFbEk67Hdx1KxwzG287W7VghwH0kio250SQ@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>
Date: Wed, 25 Feb 2015 10:47:02 -0500
Message-ID: <CAAyV7nEk6BhPYD9iE9B4V2CN1vSZXhJbSbh7z=s4XE911RquCg@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5
From: ircmaxell@gmail.com (Anthony Ferrara)

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.

>> > 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.

>> 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.

>> 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.

>>
>> "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