Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105685
Return-Path: <johannes@schlueters.de>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 54493 invoked from network); 13 May 2019 15:43:38 -0000
Received: from unknown (HELO mail.experimentalworks.net) (84.19.169.162)
  by pb1.pair.com with SMTP; 13 May 2019 15:43:38 -0000
Received: from kuechenschabe.fritz.box (ppp-188-174-57-127.dynamic.mnet-online.de [188.174.57.127])
	by mail.experimentalworks.net (Postfix) with ESMTPSA id 739C749E30;
	Mon, 13 May 2019 14:49:01 +0200 (CEST)
Message-ID: <1557751737.2875.27.camel@schlueters.de>
To: Lynn <kjarli@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Date: Mon, 13 May 2019 14:48:57 +0200
In-Reply-To: <CANS-=pfhndjEwmZ7_xsOKe=OpEhydAENvbZPpdGpF0w5JTB7xw@mail.gmail.com>
References: 
	<CANS-=pf=WSJ-X9Sp3dRgrkRcOyK9ZELJ+6AmfpFmWmRgWWxUnw@mail.gmail.com>
	 <CAF+90c-S4ToaUdkg9QXt14mPfMgcS_Kis-YXKpuzQ--050g0Cg@mail.gmail.com>
	 <CANS-=pfhndjEwmZ7_xsOKe=OpEhydAENvbZPpdGpF0w5JTB7xw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] PHP header files, restrict to declaring code only
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Fr, 2019-05-10 at 15:14 +0200, Lynn wrote:
> Hi Nikita,
> 
> By limiting a header file to declaring code only, a couple of issues
> could
> be tackled:
> 
> 1. No side effects when loading files. You can assume the global
> state
> remains the same, no
>    code is executed by this file, and no output can be sent.

Mind that this won't be side-effect free. Declaring a class/function is
a side-effect in itself.

For dealing with syntax differences we could use the declare()
statement, as used for strict_types or encoding.

A question is whether it is worthwhile to have multiple syntaxes in
parallel. This adds burden for developers using PHP, (i.e. copying code
from tutorials or other files might fail sometimes etc.) tools
processing PHP (IDEs, code analyzers, ...) and language developers (new
syntax changes have to be evaluated for both contexts)

If this were a strategy to transition to a new syntax (deprecating "old
PHP") such a mechanism would be the way to go. For just having
alternatives to avoid a syntax conflict cost imo is too big.

johannes