Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80612
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.182 as permitted sender)
MIME-Version: 1.0
Reply-To: marcio3w@gmail.com
In-Reply-To: <54B86C63.6070802@gmail.com>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <CAPwsocGyv7dp8n=_E1QfrXRSbYZXcHZAPk5F=hDLB070i=SCGA@mail.gmail.com>
 <4E2073DE-0951-498C-97BB-DDAC094F11FA@ajf.me> <9a033dd1f223f854e760924d118ab812@mail.gmail.com>
 <CAKUjMCU-57cDpG5ZbDGv10dSqx=Ey40D-WbKxKSnC6oSYOfLWw@mail.gmail.com>
 <2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com> <F3BC55CD-38CD-42B7-AE0B-A6D34E3D3875@ajf.me>
 <6105ea99002e634373c09685310e26a6@mail.gmail.com> <D39D18B9-A9E5-430E-B00A-E0DE03DAFE8C@ajf.me>
 <e131f1aaf3ae0491f958171df36211f5@mail.gmail.com> <85F6139E-6332-4645-91B8-C852B07EA62A@ajf.me>
 <12433808-9D62-48D3-B66E-74572C61BF68@zend.com> <CALW=WEAzvXde8J6iQ9msG34P7Ukhq6qQONEDvzW+duNSTP-FSA@mail.gmail.com>
 <CAOsHV+tWaDZP-ZzxQs5XZb2rYvuSNnHW1+tcURKjsMJceps8NQ@mail.gmail.com>
 <54B85C2B.9000901@gmail.com> <CAOsHV+tqOEz5mTZJOqqu_esrRVsQxPQh-eEPYV+6uRv4-NQiyw@mail.gmail.com>
 <54B86134.1020801@gmail.com> <CAOsHV+ukrb1HQCHKzbMuzYB4q_xVj1U7pqdxXvVJBCzpzRPSCA@mail.gmail.com>
 <54B86C63.6070802@gmail.com>
Date: Thu, 15 Jan 2015 23:10:02 -0300
Message-ID: <CAOsHV+ssieK3jDOqMaF9m0Rebwv89Ztxr5r5z2dJ++ySUXTAtg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Andi Gutmans <andi@zend.com>, Andrea Faulds <ajf@ajf.me>, Zeev Suraski <zeev@zend.com>, 
	Richard Quadling <RQuadling@gmail.com>, Leigh <leight@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: marcio.web2@gmail.com (Marcio Almada)

Stanislav Malyshev,

>> detriment of coercive types simply because there is no general
>> consensus about what "strict" means :)
>
> I don't see any place for "consensus" and "non-consensus" here -
> unless you want to redefine words to have arbitrary meanings so nobody
> understands you, it is pretty clear what "strict" means

People have been using the term "strict" with clearly different
meanings over the threads.
For some it means total strictness, for others just between numbers vs
strings, for others it means that coercion should
occur only when there is no data loss and there are many other meanings.

Even Nikic presented different versions of "strict" proposals on an
old article > http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-harder-than-you-think.html

That's why I said the meaning of a "strict" implementation hasn't
reach consensus but you tried pretty hard to do not understand it.
Citation again:

> I don't see any place for "consensus" and "non-consensus" here -
> unless you want to redefine words to have arbitrary meanings so nobody
> understands you [...]

You're basically stretching my words, trying to make it look mean in
some way (stop that ;)
Now I understand why folks rage quit internals once in a while...

PS: I'm out this thread, but hope the POV about the language feature
was clear enough to the objective debate.

2015-01-15 22:41 GMT-03:00 Stanislav Malyshev <smalyshev@gmail.com>:
> Hi!
>
>> detriment of coercive types simply because there is no general
>> consensus about what "strict" means :)
>
> I don't see any place for "consensus" and "non-consensus" here - unless
> you want to redefine words to have arbitrary meanings so nobody
> understands you, it is pretty clear what "strict" means - typing system
> in which the variable marked with certain type accepts only value of
> that type and nothing else. What other definition could you have in mind?
>
>> But I also don't want to have coercive type hints to occupy the best
>> "syntax slot" that could be used for more strict type checks
>
> That's fine that you want your use case to be most convenient for you,
> unfortunately that place has been already taken for years.
>
>> debate. I'm just claiming that `(int) $num` is more explicit, has no
>> BC breaks and should, IMMO, be the preferred choice.
>
> No, it should not be, and I just wrote two mails explaining why exactly
> it should not. Here's the third.
>
>> Sorry, but this is the syntax used by the manual to describe functions
>> usage, not the actual implementation. The manual can be updated. The
>
> Of course, we can rewrite the whole manual and the whole language. The
> question is - why we should make such huge changes if we already have
> this meaning and it has been there for years and it always meant exactly
> that - coercive typing for scalars - and never meant anything else?
>
>> implementation itself can't be changed after major version release.
>
> The manual is what people read and rely on. But there's a bigger issue
> that you keep ignoring - that the functions having scalar typed argument
> *are* coercive *right now*. You describe it as if it's a typo in the
> manual that can be fixed or something that happened by accident and
> nobody intended it. Nothing can be further from the truth - it's how
> weak typing has been always working in PHP. You want new feature for
> your use case? Fine, but claiming existing syntax for it and saying "no
> problem we'd just rewrite the whole manual and disregard 20 years of PHP
> history" sounds like a bit too much to ask.
>
> --
> Stas Malyshev
> smalyshev@gmail.com