Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105706
User-Agent: Cyrus-JMAP/3.1.6-532-g5582127-fmstable-20190514v6
Mime-Version: 1.0
Message-ID: <65c18760-10a8-410c-ae29-d8d2d1542ec2@www.fastmail.com>
In-Reply-To: <1557751737.2875.27.camel@schlueters.de>
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>
 <1557751737.2875.27.camel@schlueters.de>
Date: Tue, 14 May 2019 13:48:11 -0500
To: internals@lists.php.net
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP header files, restrict to declaring code only
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, May 13, 2019, at 7:49 AM, Johannes Schl=C3=BCter wrote:
> On Fr, 2019-05-10 at 15:14 +0200, Lynn wrote:
> > Hi Nikita,
> >=20
> > By limiting a header file to declaring code only, a couple of issues=

> > could
> > be tackled:
> >=20
> > 1. No side effects when loading files. You can assume the global
> > state
> > remains the same, no
> > =C2=A0=C2=A0=C2=A0code is executed by this file, and no output can b=
e sent.
>=20
> Mind that this won't be side-effect free. Declaring a class/function i=
s
> a side-effect in itself.
>=20
> For dealing with syntax differences we could use the declare()
> statement, as used for strict_types or encoding.
>=20
> A question is whether it is worthwhile to have multiple syntaxes in
> parallel. This adds burden for developers using PHP, (i.e. copying cod=
e
> from tutorials or other files might fail sometimes etc.) tools
> processing PHP (IDEs, code analyzers, ...) and language developers (ne=
w
> syntax changes have to be evaluated for both contexts)
>=20
> If this were a strategy to transition to a new syntax (deprecating "ol=
d
> PHP") such a mechanism would be the way to go. For just having
> alternatives to avoid a syntax conflict cost imo is too big.
>=20
> johannes

Another possible place such a marker could be useful is in the new prelo=
ading functionality in 5.4.  Any file that is preloaded is going to neve=
r execute again, ever.  That means preloading a file that has both symbo=
l declarations and executing global code could lead to weird results.  I=
 could see a preloader that would only try to preload symbol-only files.=


That said... most polyfill files, of which there are a decent number, do=
 some variation on:

<?php

if (!function_exists('coolness')) {
  function coolness(int $coolLevel) { ... }
}
?>

Which would then be incompatible with such a check, yet are perfectly va=
lid to preload; maybe even an especially good case for preloading.  So s=
uch a strict check is probably unwise.

Maybe it would be helpful for the various experimental "precompile PHP" =
efforts, like what Anthony Ferrara has been doing?  I've no idea there.

I appreciate the intent here, and agree most code files should be symbol=
-only, but I'm not sure there's a strong enough use case in practice for=
 it.  That said, were it to be adopted I would strongly favor a declare =
rather than a different file extension or tag.  Something like:

<?php
declare('strict_types=3D1');
declare('this file only declares symbols, error if it tries to do anythi=
ng else');

class Blah { ...}
?>

That would be the least obtrusive way of adding it, I think.

--Larry Garfield