Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78701
Return-Path: <smalyshev@sugarcrm.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 71077 invoked from network); 5 Nov 2014 03:31:33 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 5 Nov 2014 03:31:33 -0000
Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.75 as permitted sender)
X-PHP-List-Original-Sender: smalyshev@sugarcrm.com
X-Host-Fingerprint: 108.166.43.75 smtp75.ord1c.emailsrvr.com Linux 2.6
Received: from [108.166.43.75] ([108.166.43.75:58079] helo=smtp75.ord1c.emailsrvr.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id D2/10-04189-31A99545 for <internals@lists.php.net>; Tue, 04 Nov 2014 22:31:32 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by smtp26.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 1E0D2380256;
	Tue,  4 Nov 2014 22:31:29 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp26.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 63F213801D3;
	Tue,  4 Nov 2014 22:31:28 -0500 (EST)
X-Sender-Id: smalyshev@sugarcrm.com
Received: from Stass-MacBook-Pro.local (108-66-6-48.lightspeed.sntcca.sbcglobal.net [108.66.6.48])
	(using TLSv1.2 with cipher DHE-RSA-AES128-SHA)
	by 0.0.0.0:465 (trex/5.3.2);
	Wed, 05 Nov 2014 03:31:29 GMT
Message-ID: <54599A0F.2060400@sugarcrm.com>
Date: Tue, 04 Nov 2014 19:31:27 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Levi Morrison <levim@php.net>
CC: Rasmus Lerdorf <rasmus@lerdorf.com>, Andrea Faulds <ajf@ajf.me>, 
 Leigh <leight@gmail.com>,
 Robert Stoll <php@tutteli.ch>, PHP Internals <internals@lists.php.net>
References: <002601cff777$eb923430$c2b69c90$@tutteli.ch>	<CAFMT4NqJDcek6itqAUt2iOyHd2icc-tDdWsEjiRYvG1YFcc5cw@mail.gmail.com>	<000601cff80a$972e0250$c58a06f0$@tutteli.ch>	<5458937F.9020304@sugarcrm.com>	<CAPwsocFQHPDFBVtW5FBCGkz_cy-LB0AzJ48qYJ9zxafAh-G1LQ@mail.gmail.com>	<545910F1.8030904@sugarcrm.com>	<859A97F0-7C58-406A-857B-557F8AA657AD@ajf.me>	<545917A2.6000206@lerdorf.com>	<CAFMT4No6jp=KVQzRbWU7ZKBiLVtZekwmj45p-Up4EgLDyVf2ZA@mail.gmail.com>	<545977E1.2060700@sugarcrm.com> <CAFMT4NrXXw9Tj2MwR47g9XpxtiuFDM00z3v1QQNTSEjmOfH2Mg@mail.gmail.com>
In-Reply-To: <CAFMT4NrXXw9Tj2MwR47g9XpxtiuFDM00z3v1QQNTSEjmOfH2Mg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Types on the right or on the left
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> What arguments do you have in favor of doing `<return_type> "function"
> <identifier> "( <parameter_list> ")`? So far I haven't heard any

We already using "type before entity" for parameter typing, and it is a
natural way to do it, both from linguistic perspective (in English, we
say "green house", not "house: green") and it is the way used in all
languages that PHP borrowed the concepts from, such as C, C++, Java,
etc. No language I can think of (excepting Hack) does parameters as
<type> <parameter> but functions as <function> : <type> - they use or
always the former, or always the latter. Making PHP the only language
that uses half that and half this would further add to the reputation of
PHP being inconsistent and haphazard language. If we consistently used
"entity : type", it would be acceptable, though detaching somewhat from
PHP roots. But what is being proposed is to use half this and half that.
And this is not a very good idea, IMHO.

I already wrote all this in previous emails, but for those who
accidentally missed them I don't mind repeating.

>  Other examples not already included are generics and function
signatures as types.

We did not see any proposal for generics or anything else, but as
examples of C++ and Java amply prove, there's no problems working with
generics and having this syntax. In any case, we do not have any
proposals right now and any argument relating to generics whatsoever, so
telling "oh, my proposal is better because generics and other awesome
stuff that maybe will happen but I'm not telling now" is a meaningless
argument, since it does not specify any connection between your proposal
and generics - it only uses a vague dream of having generics in the
future to hint at nonexistent advantage your proposal would provide in
the present.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/