Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105684
MIME-Version: 1.0
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>
 <CADMz3wd0G_UKo5YtFDJ_SPEHHccyvHT=nX4P0WtwSpmYqazi8w@mail.gmail.com>
 <CANS-=pfCMuT645vp+ou4jVtxo-eSePTW=DbVY_ajAUqDwd8h8Q@mail.gmail.com> <CANUQDCgdJ7O3Z_6R+KSeFh_+n08+7RAxkocHzonGivHpCFoUWw@mail.gmail.com>
In-Reply-To: <CANUQDCgdJ7O3Z_6R+KSeFh_+n08+7RAxkocHzonGivHpCFoUWw@mail.gmail.com>
Date: Mon, 13 May 2019 11:59:49 +0200
Message-ID: <CANS-=pe+pzHR9khxb+HcOXLP25WKKnvry3i_XUFdSF2drG-qkA@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: Dustin Wheeler <mdwheele@ncsu.edu>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009f4bae0588c1fbd0"
Subject: Re: [PHP-DEV] PHP header files, restrict to declaring code only
From: kjarli@gmail.com (Lynn)

--0000000000009f4bae0588c1fbd0
Content-Type: text/plain; charset="UTF-8"

> Instead of introducing a declare option or special open tag, how about
> another "include" construct, that only allows side-effect free (apart
> from class loading) operations?
>
> e.g. "require_noexec 'foobar.php'"
>
> Regards, Niklas
>

Hi Niklas,

That's indeed a very interesting alternative! I've given it some thought in
regards in
the context of no side-effects and I really like the idea as it sounds
easier to implement.

With an alternative as such, I see one major roadblock, perhaps it can be
solved?

These days I personally hardly ever write require/include statements,
composer does
this for me with autoloading. For composer it would probably mean an "all
or nothing" when
it comes to picking the keyword to "require" or "require without
side-effects". This makes it hard,
if not impossible, to trigger deprecations from deprecated interfaces,
unless you use something
too hook into autoloading and check if there were `@deprecated` annotations
on the class,
interface, etc. This means that a feature that worked by default, would be
broken and risk
potential issues when upgrading.

Following this strategy, it would put the responsibility of loading the
files at the developer that
consumes the (public) API, rather than the developer that (public) API. I
believe the public API
should define whether or not it can, or must be, be loaded without side
effects without any worries
for the developer consuming that public API. This is why I initially tried
to come up with a
strategy that allows you to define it in the file (one way or another).

Note that my example with composer is tailored around my specific use-case
and that a new
function, keyword or statement might be more suitable for developers that
explicitly load their
code without autoloading.

Regards,
Lynn van der Berg

--0000000000009f4bae0588c1fbd0--