Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58326
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.170 as permitted sender)
Received-SPF: pass (google.com: domain of simonsimcity@googlemail.com designates 10.182.36.106 as permitted sender) client-ip=10.182.36.106;
MIME-Version: 1.0
In-Reply-To: <A633CF2D7C7BED41B41F1E64F25507B8069DC46D04@MAILR001.mail.lan>
References: <CAG=uTXEfTBqX7n0_zfGjB_txQFKtZXF4MOo6RHHPSRPerGeKZA@mail.gmail.com>
	<CAGovj_O5UQx9aAaYg302i-kKp13CtBKNLmQ48OLHNvk61rM1sw@mail.gmail.com>
	<1330357150.2159.30.camel@guybrush>
	<CAGovj_MUt60EJfG8a7r-cqrC2PKsi8mqh6v_iyNoRDq8q-jh2Q@mail.gmail.com>
	<CAH-PCH6Bre5yzc6r3zxEj3=zZY0PHDOCVQ0s=f8JBDSPnK+5Fw@mail.gmail.com>
	<CAAyV7nFmfhb97CGAK1ZAkp9qb3oCPxbUDnS-Z-v3cP2APcYs=g@mail.gmail.com>
	<CAKOpQSwTGMcuGs5fDvA0kF7QJamooU7hnqtDFMaCh80amt7kcQ@mail.gmail.com>
	<CAKOpQSx_tJfrRx4uRDfcP94bN1qYw=WOktCKf3Xt-AizN=Lk0A@mail.gmail.com>
	<ee25d764561a39bb5b4459b3bd7e7089.squirrel@www.l-i-e.com>
	<A633CF2D7C7BED41B41F1E64F25507B8069DC46C3A@MAILR001.mail.lan>
	<CAKOpQSyxDDqiaXQbVZHE-5K_hOS8dOx4g6Bsj+yJ9BjmTOMh8Q@mail.gmail.com>
	<693e15008681dfe7372eaea66214f8a8.squirrel@www.l-i-e.com>
	<CAKOpQSxh78xMqm=aQ1jBx1T4VJ-BfKHQkxha4B=mHe6TAeiQGw@mail.gmail.com>
	<A633CF2D7C7BED41B41F1E64F25507B8069DC46CEF@MAILR001.mail.lan>
	<CAKOpQSyyXfuCmcx63EgoQa-pkUxT+STS=TNOJvTQ1JEwG=VKow@mail.gmail.com>
	<4F4D5D44.5090307@developersdesk.com>
	<CAKOpQSzi1zvYiLTc67gAzosfhQY6ueuJjBkKqRymhYe0nMPaZQ@mail.gmail.com>
	<A633CF2D7C7BED41B41F1E64F25507B8069DC46CFE@MAILR001.mail.lan>
	<CAKOpQSxZASqgh94ZX0kuaaqHUVqAz3L_+rRLKxmbzZ5k5WTFkg@mail.gmail.com>
	<A633CF2D7C7BED41B41F1E64F25507B8069DC46D04@MAILR001.mail.lan>
Date: Wed, 29 Feb 2012 09:58:53 +0100
Message-ID: <CAJWj5+GcADDRW0Vk6deyxh6K-y-S8v-2xjizq6F-Rncc24=AWg@mail.gmail.com>
To: John Crenshaw <johncrenshaw@priacta.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04447eeb86339004ba168d2c
Subject: Re: [PHP-DEV] Scalar type hinting
From: simonsimcity@googlemail.com (Simon Schick)

--f46d04447eeb86339004ba168d2c
Content-Type: text/plain; charset=UTF-8

Hi, John

I personally do not care about weak or strong variables at all ... I only
want what Arvids suggested last time:

> test(1, 2); // 2;
> test("1", 2); // 2
> test("1aaa", 2); // E_NOTICE or E_TYPE and result 2
> test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type
hint now.
>
> It's really what the most people want. Simple, easy to pick up (object
> and array already have this) and is just optional.

I count myself as a part of *most people* in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get an
error if you try something like this:

function foo(SimpleClass $a) {
  $a->getName();
}

foo("Test");

If you now get *method called from an non-object* or a message that you
have passed a value that's not compatible with *SimpleClass* ...

I'd like to split this discussion in parts:

   - just type-hint in functions (as we have it with classes and arrays) or
   bind a variable to a strict type?
      - should it then also be possible bind variables to a specific class
      or interface?
   - should we go for weak or strong types?
      - the type-hint is also weak in one way because it accepts all that's
      compatible with the given type.

Bye
Simon

2012/2/29 John Crenshaw <johncrenshaw@priacta.com>

> I would personally be inclined towards something simpler like E_NOTICE or
> E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we
> should be consistent, and the consistency argument may make the difference.
>
> There may be a strong case for changing the error level on all type hints
> to something simpler (or new, like E_TYPE), but I think that might be
> better to tackle that in a separate discussion.
>
> John Crenshaw
> Priacta, Inc.
>
> From: Kris Craig [mailto:kris.craig@gmail.com]
> Sent: Tuesday, February 28, 2012 8:40 PM
> To: John Crenshaw
> Cc: Rick WIdmer; internals@lists.php.net
> Subject: Re: [PHP-DEV] Scalar type hinting
>
> I wouldn't mind that, though I'm concerned that it may not be sellable
> because some people on here have expressed a strong opinion that this
> shouldn't throw anything more than a notice or a warning at most, something
> that I and others strongly disagree with.  The logical approach, to me at
> least, is to follow the example of include() and require(); i.e. they're
> both identical except that one throws a scary error while the other one is
> just a warning.
>
> I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
> alienate too many people for us to be able to get this through.  Though
> it's possible I might be overestimating that factor.
>
> --Kris
>
> On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw <johncrenshaw@priacta.com
> <mailto:johncrenshaw@priacta.com>> wrote:
> > On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer <vchkpw@developersdesk.com
> <mailto:vchkpw@developersdesk.com>>wrote:
> >
> > > On 2/28/2012 2:58 PM, Kris Craig wrote:
> > >
> > >  strong int $a = "1"; // Converts to 1.  May or may not throw an error
> > > (I'm
> > >> still on the fence).
> > >>
> > >
> > > It this is an error, it is no longer PHP.
> > >
> >
> > @Rick Though I'm not sure I'd agree with the overly broad "it is no
> longer PHP" hyperbole, I think the basic point that it would be a
> significant departure from the current model has merit.  So ok, you've
> convinced me.
> That example should not throw any errors.  I'm officially no longer on the
> fence with that.  =)
> >
> > --Kris
> OK, if we're all on the same page there, I think this means that there is
> no significant difference between the "strong int" and "weak int" in your
> proposal (the only remaining difference being the level of error raised
> when it cannot be converted, which IMO is not substantial enough to deserve
> a keyword.) I'd prefer to just pick one error level to use
> (E_RECOVERABLE_ERROR would be the most consistent) and keep everything
> simple.
>
> John Crenshaw
> Priacta, Inc.
>
>

--f46d04447eeb86339004ba168d2c--