Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78632
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.46 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <001d01cff829$5010a750$f031f5f0$@tutteli.ch>
References: <002601cff777$eb923430$c2b69c90$@tutteli.ch>
	<CAFMT4NqJDcek6itqAUt2iOyHd2icc-tDdWsEjiRYvG1YFcc5cw@mail.gmail.com>
	<000601cff80a$972e0250$c58a06f0$@tutteli.ch>
	<5458937F.9020304@sugarcrm.com>
	<0776A65F-D49A-4E8C-9771-6B5E5C4EA77E@ajf.me>
	<CAGAGxbYhQ5iHdXnNk3vj33iapzV2A5NoYtCct1-=wbUb-oN+wg@mail.gmail.com>
	<001d01cff829$5010a750$f031f5f0$@tutteli.ch>
Date: Tue, 4 Nov 2014 12:46:23 +0000
Message-ID: <CAGAGxbatk-m4AnGE5c3nmFVQT0J+wcOb0c-aWaQR_HcXwUr5sw@mail.gmail.com>
To: Robert Stoll <php@tutteli.ch>
Cc: Chris Wright <cw@daverandom.com>, Andrea Faulds <ajf@ajf.me>, 
	Stas Malyshev <smalyshev@sugarcrm.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c15d7ec7c9da050707d9a0
Subject: Re: AW: [PHP-DEV] Types on the right or on the left
From: cw@daverandom.com (Chris Wright)

--001a11c15d7ec7c9da050707d9a0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 4 November 2014 12:17, Robert Stoll <php@tutteli.ch> wrote:

>
> > -----Urspr=C3=BCngliche Nachricht-----
> > Von: are.you.winning@gmail.com [mailto:are.you.winning@gmail.com] Im
> Auftrag von Chris Wright
> > Gesendet: Dienstag, 4. November 2014 12:51
> > An: Andrea Faulds
> > Cc: Stas Malyshev; Robert Stoll; PHP Internals
> > Betreff: Re: AW: [PHP-DEV] Types on the right or on the left
> >
> > On 4 November 2014 10:32, Andrea Faulds <ajf@ajf.me> wrote:
> >
> > >
> > > > On 4 Nov 2014, at 08:51, Stas Malyshev <smalyshev@sugarcrm.com>
> wrote:
> > > >
> > > > I agree, this is not a very good situation. It would be much better
> > > > to take a systematic approach to this, but this is impossible since
> > > > there is no systematic approach to strict typing in PHP, just some
> > > > pieces here and there. I think this is not right, but obviously man=
y
> > > > people here disagree and are happy to have the inconsistent syntax.
> > > > I don't see why "public Foo function bar()" would be so much worse
> > > > than "public function
> > > > bar() : Foo"  but for some reason this possibility wasn't even
> > > > considered as far as I can see.
> > >
> > I thought it was inconsistent, but after discussions on StackOverflow, =
I
> > > don't think it actually is. Return types describe the return type of =
a
> > > function, not the type of a function. So there's no reason they have
> > > to go before the function name like parameter types do.
> > >
> > >
> > So, in a sentence:
> >
> > In PHP, input types go on the left and output types go on the right.
> >
> > This sounds like a convention that could be established and followed,
> and no-one could reasonably call it inconsistent if it
> > was adhered to.
>
> That is an interesting thought. Yet, where would you put the type of an
> out parameter then?


I wouldn't, because this wouldn't ever make sense in PHP. I'm not a fan of
out parameters in general in PHP, but enforcing the output type of a
variable can't ever make sense in PHP from an implementation perspective
without sacrificing some dynamic features that won't ever disappear - I'm
sure it could be done, but not without a huge and unacceptable performance
penalty.


> Nevertheless, you could phrase your convention differently so it makes
> more sense and  well..  in the end we can do whatever we like in PHP and
> call it xy-convention and the user will have to pick it up and learn it
> (quite similar to array functions where usually the first argument is arr=
ay
> and suddenly it is not the first parameter as with array_key_exists,
> array_map or array_search). Sure it is no big deal, the user should be ab=
le
> to pick up the convention quickly but we could facilitate it, make it
> easier for the user, more intuitive, in order that the user has a steeper
> learning curve.  And the time to decide what direction PHP should take is
> now with PHP 7.
>

Please remember that PHP 7 is not the last major version of PHP. The things
we do now are set in stone, but they do not mean that something else cannot
be done in the future to build on top of them, as long as they do not
conflict.

I guess it's worth noting that my *personal* opinion is that I'd also
rather have the function return type declaration on the left (I'd also like
to drop the requirement for the "function" keyword in method declarations),
but since there are a number of reasons why this no longer makes sense, and
will never make sense again, I didn't hesitate to vote in favour of the
current proposal because more than anything else I think the feature is
what is important, and I know how much work has been put in to ensuring
that the proposal satisfies as many concerns as possible. There will never
be a better proposal than this.

--001a11c15d7ec7c9da050707d9a0--