Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80575
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A6B06BAB-F8C8-4BFC-98F5-21AD572D65A2@ajf.me>
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>
	<CALrkBjaBgvfdqLqSPDCGfHJD7XEOTOba9yg5ttHN7V1KyFA1-w@mail.gmail.com>
	<A6B06BAB-F8C8-4BFC-98F5-21AD572D65A2@ajf.me>
Date: Thu, 15 Jan 2015 11:07:39 -0600
Message-ID: <CALrkBjbmKAiDw+UCJsnugWxChvBio5FUuuEOVcDS5FAqYNrStg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Zeev Suraski <zeev@zend.com>, Richard Quadling <RQuadling@gmail.com>, Leigh <leight@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114079d4bb7482050cb3e4ec
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: pencap@gmail.com (Mike Willbanks)

--001a114079d4bb7482050cb3e4ec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Andrea,

>
>
> > On 15 Jan 2015, at 16:55, Mike Willbanks <pencap@gmail.com> wrote:
> >
> > I actually quite disagree with that statement.
>
> I don=E2=80=99t understand. I said "either approach to scalar hints will =
upset a
> large portion of the community=E2=80=9D. Are you not demonstrating that p=
oint, in
> that you don=E2=80=99t like the strict approach?
>

Sure, I am demonstrating that a bit, but I am of the opinion that either
will work but not both.  Whilst I prefer weak, I would take strict as well
to have "something".  Having both would be a very strange inconsistency.
Sorry for not being more clear.  I would not be upset in either condition
but I certainly lead toward a certain direction.


>
> >  Both as a library/framework developer and a user land developer I find
> strict typing to be more of an issue.  For instance:
> >
> > function foo(int $foo)
> > foo('23');
> >
> > This would be a pain and cause constant glue from userland:
> > Option A: Force Cast aka (int) '23'
> > Option B: Check for digits via ctype_digits then force cast
> > etc.
> >
> > To provide more of a point here, variables coming from HTTP are always =
a
> string, this makes strict casting a troubling item, considering that the
> main way of fetching input is coming from the web specifically.  I'm
> certain this would also affect other areas as well such as reading csv
> files and more.  To me this point alone makes a vastly strong statement
> against strict typing and as such, it would make life far more difficult
> for library developers and user land developers alike.
>
> Well, this RFC doesn=E2=80=99t force you to use strict type checking. Qui=
te the
> opposite.
>
>
> > I agree with the others in that declarative syntax to change it is a ba=
d
> idea.  It actually reminds me of ECMAScript 5's "use strict" (
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_=
mode)
> condition.   Changing the definition based on user land scripts can lead =
to
> bugs and inconsistencies in a library developers purpose of a package and
> cause bad conditions.  It also means that then a library developer would
> need to handle conditions on both sides (when in weak vs. strict).
>
> No, the library developer would never need to =E2=80=9Chandle both cases=
=E2=80=9D. Your
> library always gets the type it asks for. The RFC is quite clear on this.
> Your code will always behave exactly the same.
>

I may not have described this clearly.  If I make a library with a method
that states an int, the declarative syntax now makes me have to take both
due to your earlier comment on that userland would define the condition.
This means that if I declared handling inside my library to be strict but
the caller was in weak, I would need to handle that condition.  Now from
that perspective I cannot rely that I am in strict and would have to handle
the default weak even although I declared in my class that i wanted strict
mode which only affected the code inside of that file.  That's ultimately
what I am saying and why I am stating it would have to handle both
conditions.  In reality, you'd always act as if you were in a weak mode
supporting that case.

--001a114079d4bb7482050cb3e4ec--