headers
Kris Craig | 1 Mar 2012 01:05
Picon
Gravatar

Re: [PHP-DEV] Scalar type hinting

 <at> Simon Well said!  For some reason, the issue of typing in the PHP and
other programming communities brings out a lot of emotion in people.  Given
some of the heated rhetoric we've seen, you'd think we were debating
whether Roe v. Wade should be overturned lol.

I think it is important that we try to remember to be civil, on both
sides.  Falling into cliche hyperbole, condescention, and personal attacks
just makes us look immature to the outside world IMHO.  I'll try to do my
part and not fly off the handle so much whenever somebody jumps in with a
dismissive, patronizing comment relating to something that was already
addressed earlier.

Regarding the RFCs, just to clarify my earlier remarks, I should mention
that the current policy, at least as I understand it, does not provide for
expiring old/abandoned RFCs.  The idea that it should was just a
recommendation on my part.  That said, I think you've got the right idea by
looking at previous RFCs for insight into this!  All I was saying is that,
when it comes time to put forth our own proposal(s), it would probably be
easier to write it from the ground up instead of trying to modify a bunch
of older ones.  =)

Oh and if anybody has any thoughts on the suggestion I made earlier about
adding "secondary questions" to the voting procedure (please read it before
commenting), I'd love to hear them!  I think that could be very helpful in
future RFCs, so if there's any interest I'll go ahead and draft one for
this.

--Kris

On Wed, Feb 29, 2012 at 3:56 PM, Simon Schick
(Continue reading)

Permalink | Reply | 6 comments |
headers
Simon Schick | 1 Mar 2012 01:18
Gravatar

Re: [PHP-DEV] Scalar type hinting

Hi, all

What's next?

I think the next step would be to write down a good Introduction,
Requirement, Solution and Examples.

As we had some discussions and ideas around here I think we came to a
proper place where we could write the first draft and discuss it after
writing it down in one place.
I wont have the time tomorrow but I'll try my best to get it done at the
weekend.

If someone else has a good overview and wants to write the RFC, just go
ahead and ping me when you've started.

 <at> Kris:
I like the idea of having a second vote-level. The first level could be
"Like / Dislike this feature" and the second one could be "Like Solution1 /
Like Solution2 / Like Solution3"

Bye
Simon

2012/3/1 Kris Craig <kris.craig <at> gmail.com>

>  <at> Simon Well said!  For some reason, the issue of typing in the PHP and
> other programming communities brings out a lot of emotion in people.  Given
> some of the heated rhetoric we've seen, you'd think we were debating
> whether Roe v. Wade should be overturned lol.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Clint M Priest | 1 Mar 2012 01:45

RE: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers

As much as I would love to have __castTo() and __assign() I have to agree with Stas here that it fundamentally
changes the mechanics of if($object) and unfortunately turns that simple if statement into a possible
hour long hunt to find the code that is doing the damage, if it is even considered a possibility by someone
reading the code.

For the record, I really have only ever needed something like __toArray() so that objects implementing
ArrayAccess could be passed to array internal functions.

I am interested in object natives though, which this is leading in the direction of.

-Clint

-----Original Message-----
From: Stas Malyshev [mailto:smalyshev <at> sugarcrm.com] 
Sent: Wednesday, February 29, 2012 1:48 AM
To: Anthony Ferrara
Cc: internals <at> lists.php.net
Subject: Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers

Hi!

> Hey all,
>
> I've created a draft version of the RFC for implementing __castTo() 
> and __assign():
>
> https://wiki.php.net/rfc/object_cast_magic

I think having cast method may have merits, though use cases where objects need to be converted to scalars
that aren't string are very limited, and cases where they need to do so transparently are almost
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kris Craig | 1 Mar 2012 01:55
Picon
Gravatar

Re: [PHP-DEV] Scalar type hinting

 <at> Simon If it's ok with you, I would like to set this aside briefly and
divert our attention toward the RFC voting thing, primarily because I think
that will make the drafting process much easier and less confusing when
we're ready to start working on the typing RFC initial draft.  Any
objections?

If not, I'll go ahead and draft an RFC for these proposed amendments
sometime today or tomorrow when I get a spare moment.  If anyone has any
thoughts on this, please share them!  Thanks!

--Kris

On Wed, Feb 29, 2012 at 4:18 PM, Simon Schick
<simonsimcity <at> googlemail.com>wrote:

> Hi, all
>
> What's next?
>
> I think the next step would be to write down a good Introduction,
> Requirement, Solution and Examples.
>
> As we had some discussions and ideas around here I think we came to a
> proper place where we could write the first draft and discuss it after
> writing it down in one place.
> I wont have the time tomorrow but I'll try my best to get it done at the
> weekend.
>
> If someone else has a good overview and wants to write the RFC, just go
> ahead and ping me when you've started.
(Continue reading)

Permalink | Reply | 4 comments |
headers
John Crenshaw | 1 Mar 2012 02:16
Gravatar

RE: [PHP-DEV] Scalar type hinting

> If it errors out or throws an exception, it's strict typing, regardless of naming.

Actually, for purposes of this discussion, "strict" is defined. It means "PHP complains about
(function(int $n){})('1'), even though it could have easily converted it." The majority of arguments in
the past, and especially those that have caused the typing discussions to fall apart, have centered
around reasons why this sort of typing is bad. Strict, by this definition, is totally off the table in this
discussion. Period.

With respect to E_RECOVERABLE_ERROR, nobody seems especially attached to this, except that it is
consistent with current type hints, so it is the logical choice. A consistent alternative would be a new
E_TYPE error (and convert existing type hints to use that), but that would be a BC break and expands the
scope of the proposal more than I think some people are comfortable with (myself included).

> Are you essentially telling us we all have to waste our time again just because 6 months have passed?

No, we're discussing this again because for the first time we have a set of terminology that we can use to
explain how this is different from the terror that has primarily been avoided in the past.

I'm in favor of moving the discussion elsewhere while details are fleshed out and carefully compared to the
historical arguments, but so far there has been no consensus on where to move this.

I'll personally resist any attempt to submit anything that isn't substantially different from prior
proposals and/or that doesn't include solutions to the problems previously identified.

John Crenshaw
Priacta, Inc.

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Crenshaw | 1 Mar 2012 02:16
Gravatar

RE: [PHP-DEV] Scalar type hinting

> Hi, all
>
> What's next?
>
> I think the next step would be to write down a good Introduction, 
> Requirement, Solution and Examples.
>
> As we had some discussions and ideas around here I think we came to a 
> proper place where we could write the first draft and discuss it after 
> writing it down in one place.
> I wont have the time tomorrow but I'll try my best to get it done at 
> the weekend.
>
> If someone else has a good overview and wants to write the RFC, just 
> go ahead and ping me when you've started.
>
>  <at> Kris:
> I like the idea of having a second vote-level. The first level could 
> be "Like / Dislike this feature" and the second one could be "Like 
> Solution1 / Like Solution2 / Like Solution3"
>
> Bye
> Simon
>

An RFC would be WAY premature. We still haven't even consolidated the historical arguments. If you create
an RFC blindly without carefully scrutinizing the prior analysis and measuring against prior arguments
you'll be the next in a long line of failures.

John Crenshaw
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Crenshaw | 1 Mar 2012 02:16
Gravatar

RE: [PHP-DEV] Scalar type hinting

> -----Original Message-----
> From: Kris Craig [mailto:kris.craig <at> gmail.com] 
>
>  <at> Richard I think you made a very good point.  Should we treat a float => int mismatch the same as we would a
string => int mismatch, or should the former fail more gracefully?  I can see good arguments for both.
>
> --Kris

I'm beginning to think that the type hinting question is too closely related to the dirty secrets of type
juggling to resolve them separately. You may have to either discard consistency, or else fix the problem
of silent bizarre conversions at the same time ('foo'==0, '123abc'=123). Fixing the conversions is a BC
break though.

John Crenshaw
Priacta, Inc.

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 21 comments |
headers
Kris Craig | 1 Mar 2012 02:46
Picon
Gravatar

Re: [PHP-DEV] Scalar type hinting

I was thinking something more along the lines of simply throwing an error
if, say, (int) $a != $a.... *if *$a is defined as an integer.

--Kris

On Wed, Feb 29, 2012 at 5:16 PM, John Crenshaw <johncrenshaw <at> priacta.com>wrote:

> > -----Original Message-----
> > From: Kris Craig [mailto:kris.craig <at> gmail.com]
> >
> >  <at> Richard I think you made a very good point.  Should we treat a float =>
> int mismatch the same as we would a string => int mismatch, or should the
> former fail more gracefully?  I can see good arguments for both.
> >
> > --Kris
>
> I'm beginning to think that the type hinting question is too closely
> related to the dirty secrets of type juggling to resolve them separately.
> You may have to either discard consistency, or else fix the problem of
> silent bizarre conversions at the same time ('foo'==0, '123abc'=123).
> Fixing the conversions is a BC break though.
>
> John Crenshaw
> Priacta, Inc.
>
Permalink | Reply | 1 comment |
headers
Adam Jon Richardson | 1 Mar 2012 02:56
Picon

Re: [PHP-DEV] Scalar type hinting

On Wed, Feb 29, 2012 at 8:46 PM, Kris Craig <kris.craig <at> gmail.com> wrote:

> I was thinking something more along the lines of simply throwing an error
> if, say, (int) $a != $a.... *if *$a is defined as an integer.
>
> --Kris
>
>
> On Wed, Feb 29, 2012 at 5:16 PM, John Crenshaw <johncrenshaw <at> priacta.com
> >wrote:
>
> > > -----Original Message-----
> > > From: Kris Craig [mailto:kris.craig <at> gmail.com]
> > >
> > >  <at> Richard I think you made a very good point.  Should we treat a float
> =>
> > int mismatch the same as we would a string => int mismatch, or should the
> > former fail more gracefully?  I can see good arguments for both.
> > >
> > > --Kris
> >
> > I'm beginning to think that the type hinting question is too closely
> > related to the dirty secrets of type juggling to resolve them separately.
> > You may have to either discard consistency, or else fix the problem of
> > silent bizarre conversions at the same time ('foo'==0, '123abc'=123).
> > Fixing the conversions is a BC break though.
> >
> > John Crenshaw
> > Priacta, Inc.
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Jon Richardson | 1 Mar 2012 03:01
Picon

[PHP-DEV] Scalar Type Intentions

PHP currently allows users to provide type hints for functions and methods,
although the type hints are currently limited to objects and arrays:
http://en.wikipedia.org/wiki/Type_system#Variable_levels_of_type_checking

Restricting the type hinting to arrays and objects makes sense, as PHP's
type juggling (similar in many ways to JavaScript's), a core feature of the
language, performs automatic conversions between scalars as determined by
context:
 http://php.net/manual/en/language.types.type-juggling.php

However, the lack of scalar hinting does limit the ability of a developer
to declare his/her intentions for function/method parameters. A non-hinted
parameter expecting a scalar could be sent an object or an array, breaking
the expectations (and much of the time, the functionality) of the code.
That is to say, there is a value in declaring what the parameter IS NOT,
too.

For example, the function below could have an object or array passed as the
first argument, even though the expectation is a scalar:

function foo($arg){
   // $arg is supposed to be a scalar and will be used as an int
}

*What if PHP added the hint scalar?* The example could be rewritten as:

function foo(scalar $arg){
   // $arg is supposed to be a scalar and will be used as an int
}
(Continue reading)

Permalink | Reply | 18 comments |

Gmane