Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58707
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A633CF2D7C7BED41B41F1E64F25507B8069DC4714C@MAILR001.mail.lan>
References: <CAJRMtAGqZCWThbZVztGN3-FyQ4MkJAs=uO_V-6pUCy9q2aAaZw@mail.gmail.com>
	<CAKOpQSyas7HSDXD5bftK9o18ucYAfQvxRtTUjYOgRSv_4nY-9A@mail.gmail.com>
	<CAJWj5+EQhhYDTh8DHwv2N4pk8FQybX3P5H292BGixbHSLB7k3A@mail.gmail.com>
	<A633CF2D7C7BED41B41F1E64F25507B8069DC4714C@MAILR001.mail.lan>
Date: Tue, 6 Mar 2012 19:02:45 -0500
Message-ID: <CAAyV7nFF2rohMyRY8QdCpvWXPqeCsudwuu3Dc695qG4zG4fBMQ@mail.gmail.com>
To: John Crenshaw <johncrenshaw@priacta.com>
Cc: Simon Schick <simonsimcity@googlemail.com>, Kris Craig <kris.craig@gmail.com>, 
	Raymond Irving <xwisdom@gmail.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Scalar Type Hinting
From: ircmaxell@gmail.com (Anthony Ferrara)

John,

> Sorry, I disagree. This is nowhere close IMO, and silence doesn't denote =
consent in this case. I actually basically stopped participating when it be=
came apparent that people were determined to rush head first into creating =
a doomed RFC without any process to ensure that historical arguments were c=
onsidered and addressed, with minimal attention to feedback, and with no co=
ncern for syntax (proposed syntax is as bad as the namespace syntax).

Well, my take on it was that thinking out-loud in a thread is not
going to get us anywhere with nothing to base the conversation on.  So
I picked an option and proposed it.  As now, we can base the
conversation around a real implementation.  Don't like the syntax?
Great!  Let's find a better solution.  But I felt that it was more
important to put a base for the conversation, rather than just letting
it wander aimlessly.

> I'm in favor of addressing the type hinting issue, but I'm opposed to thi=
s RFC. It is crippled, confusing, and has a plethora of unaddressed issues.

Then point out the issues.  Help improve it and make it something that
*should* go in the core.  That's why it's still in draft mode.  I
didn't propose it, or put it for discussion, I put it in draft for
that very reason.

As far as it being crippled, I'm not sure what you mean, just because
it's only doing casting?

As far as confusing, it is?  I thought this was actually one of the
more straight forward proposals, since it re-used so much from the
core (meaning that it doesn't add new behavior, it re-uses existing
behavior).

As far as having a plethora of unadressed issues, I'm absolutely sure
it does.  But I haven't seen a single one put out there so that it can
be fixed...

> The object cast has similar problems, and although I recognize the value =
of this sort of functionality, the current proposal seems to mostly ignore =
a number of critical problems that were raised when it was discussed on the=
 mailing list.

Which were?  The critical problems that I saw on the list were mostly
related to the original proposal wrapping set() with __assign() (which
this proposal removed).  The only known issues that I know of that
remains is with the __toScalar() part (which in worst case can be
removed from the proposal).



These are RFCs.  I am (as their author) explicitly asking for your
comments and contribution.  They are not set in stone in the least...
In fact, the only way they would get to the point where I would
propose them is with enough input and overview that it was mature.
They are not mature now.

Can we make them mature?

Thanks,

Anthony