Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106355
To: PHP internals <internals@lists.php.net>
References: <CAF+90c_Ctjja=8fR-uBWL1wDxZge771yMujMhaR_R2seKXciYw@mail.gmail.com>
 <CAF+90c8JhV6-aQrsvW8u_xGB-wHmyObEU1Chd64J+x3tkKogQQ@mail.gmail.com>
 <9ADC8994-9D3C-4810-A2DB-6FB81D513098@gmail.com>
 <CABdc3WqxvucnCk7rd-Y2YuNn_dCvh5atNagwCqo8gp9NjMt_aQ@mail.gmail.com>
 <CANS-=pcp=-t4-cEHK8vbuNAaMBLSjmoL94h-TXKtHm0v8Ptkqg@mail.gmail.com>
 <CALKiJKorD5xayU1QYtd_XMEz7Zkx+etWs3k3DGZS3O9zPnk7mQ@mail.gmail.com>
 <CABdc3WrgSwFtoxzOpUa=_09N6vPt-CU_qFhCmZM9GVJMMQ7Gow@mail.gmail.com>
 <CAF+90c82zYeUkn3QRiPDFzf4B3cdF188TFGOMMXjwMAJ1UW6DQ@mail.gmail.com>
Openpgp: preference=signencrypt
Autocrypt: addr=smalyshev@gmail.com; prefer-encrypt=mutual; keydata=
 mQMuBE9mqaARCACFSqcGmNunkjQQu3X+yXnTmFeEkvM4JXZTOBdR8aEevNGmmFEfyvjaDjWi
 9hcwp4E/lYtC+P7VsVjM1OSX9eq0jC/lGL0ZyRXek+mNy0n5H1NSuTpf9Y18LMqhc4G+RU+L
 cNiZ9K0DJuOOvNLPxW7OHZguxb3wdKPXNVa2jyRfJAKm2uaJJMT1mTmFT9a0Q8SKr+mUrrJk
 uG0H2o6SzrKt8Wwoint1eh67zVsJaJtQFchnEZnlawIcqP2yC4nLGR3MkubowxoEBYCZet18
 aHVVRbvpG2Qtob8Lu5xrsGbmXymTkHTdpvkfcJFADa8MzOL90zOxXwbGfbIZOlh5En8jAQCX
 lfnx2eQL3BSW/6XANa51dbWiEp1d1BAkpGKtZvlk0Qf+M9WAi+9aXMe3xP5krxtgnRNUf2WN
 6Zdy2MxL1RRJCFbytLhl0ronC49BsGYVGshdEH8xhBbiIOJKuVZ/DTl9bEm7P9c7CC7iJyVC
 khUAhouH6xzZQNLR+RU+QebYzXypVfl99Qk7EdMmr/WAZCHLuvanyqepC5EBsa3VnAfQemSN
 oBeGBKWWLiOsPjvS72+y1z4RUMAfXHn4l/sFMt8zt7/74AmJPwZquV41p4mPO12V4+xPyc6R
 sB84sfsk2QVivU8w8AkvGQeYjXoz7Iwao95+fWteVzZ36KRQvUckP8pGjHlDXnHxJ0HI1I/k
 OBZSjwRwUf0dd73y6erPhbLk+gf+NdI3H9KGJBzG5/rVyWKwUeQ9d5ud4jTJRkQGvAP5pg76
 vEa9dogbpe4W5Z+0BfbiJSnQmQWSHiZddj/t33ptbup44Ck6ZTgdlmFYMLF1hR47PIZTDKER
 EuKYGci/vq8snZvEJP9YCw/TtiHcMdrMKcY/+Lp8lQO0GHLPB9glVhnC0db6l1Xpg1CMI8/R
 ozBMcij30EgATggC/y2zbiqAFoS9FN9nXPbe4phStqABEyeZ+nXudt7PUYTjVgcrqo8bHZCi
 sBobWC7OnKyUzxVxzUeuPkIfmZuzkLaMw2McQdvwwsNvQ0DzaLP30c1Xsm/7EIYJcOWpzlVJ
 5QrdmE0/BbQyU3RhbmlzbGF2IE1hbHlzaGV2IChQSFAga2V5KSA8c21hbHlzaGV2QGdtYWls
 LmNvbT6IegQTEQgAIgUCT2aqtAIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQL3lW
 vF2gS12XMwD9HuRIolSwIK77u8EY461y2u6sbX36n5/uo/LDQuxoi3sA/0MvpnvzOhv9Iufv
 vsZEj3E7i3h+iD5648YMwfTFCij+uQINBE9mqaAQCADfZPMpjZkkGZj3BY/7ApoLq4mwqzbh
 +CpLXwNn20tFNvSXfb8RdeXvVEb7Scx+W9qYpiaun2iXJgCVH8fgpZpR856ulT1q6uCG++CX
 ubEvip/eJkZl93/84h04KQJwsgOrAh0Om3OePRn8Pr+++0LNS0EL8uX/YHeTOGOnnmTqYTey
 SBVFdov6L4mepddfjekicKQqhL7mZh/xuq29JijT0uNNX8v4vDWQDu5dlAcdd+uB3gcXMD/P
 ginD11zp+6wtrWCm/+yBqpvDwXQX5PGUnwvbRfl7Ay3MmwmoXiecZMg0dwTSc7e0lhB4HGRH
 ZdBMJB4rHUVGdzqujK/ctOvrAAMFB/0Utb76Qe6sCMlHxVAmeE/fbo7Pi05btZ/x01r67dHf
 aMSP0riCKJ7M0OW+jAXtu9+z/BVnYisW67WWfxl2cS5tZDgiHgJARXWUOO72+sScHP8KQmTl
 1z16gyKbwY3SmyBkwcpOL35nhUWNLy93syPoY6sZUTikr2bZYukHDQ33XBPs4e6MbWKfsa9q
 aVmnlOF3k5UqChjutfHaEa4Q7VP4wBIpphHBi9MI16oJIzzBPbGl2uoedjwiZ6QeQZnSuOVY
 ZxU2d3lRA8PrtfFN1VSlpEm/VcAvtieHUYWHN0wOu+cp3Slr5XJVNjTjJhl28SlinMME54mK
 AGf2Ldr/dRwXiGEEGBEIAAkFAk9mqaACGwwACgkQL3lWvF2gS126EQD/VVd3FgjLKglClRQP
 zdfU847tqDK4zJjbmRv5vLLwoE0A+wbrQs7jVGU3NrS0AIl5vUmewpp2BKzSkepy23nWmejw
Message-ID: <e84e9e1e-b4f6-6127-ff81-fad598fab40c@gmail.com>
Date: Tue, 30 Jul 2019 12:33:48 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
 Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c82zYeUkn3QRiPDFzf4B3cdF188TFGOMMXjwMAJ1UW6DQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> If we want to evolve the language without breaking backwards compatibility,
> we need to provide a way for gradual migration of the ecosystem: A library
> should be able to opt-in to breaking changes, while remaining usable by
> downstream consumers. Conversely, an application should be able to opt-in
> to breaking changes, while still being able to use an older library.

This assumes breaking changes are necessary for evolution. I am not sure
this is actually true. Java is 21 years old, and I think the code I
first wrote when I learned Java in late 90s would still compile today
(even though nobody would probably want to run it :).
Javascript is 23 years old, and the only thing I can think of that may
break BC is "use strict", which is also local and just one option.
C++ had a myriad of changes lately, and is 34 years old, but I am pretty
sure code written a decade ago - discounting library changes, etc. -
would still compile today.
I think the assumption that we *must* break old code to be able to
evolve is not correct. Surely, certain directions of evolution - like
converting PHP to strictly-typed language - would require that, but
that's not the only direction possible.

> 3. Support per-directory declares, which is the direction I was planning to
> explore next. This is based on the premise that all library files are part
> of some top-level directory, which I think is a fairly safe premise (note
> that the "directory" could also be a phar file).
> 
> The actual intended use (similar to the namespace-based variant) is that
> people will specify their declares in the composer.json file, and composer
> then includes a call to declare_directory() or similar as part of the
> autoloader. Projects not using composer have the choice of issuing an
> explicit call.

Note this also means that syntax and semantics for each file is
runtime-defined and can change any time. With obvious implications for
preloading and opcode caching. Moreover, there could be a situation
where some code includes a file with one set of options, and then
declare_directory() happens that changes the options and another code
includes the same code assuming different set of options. I have no idea
what is supposed to happen in this situation. Since declare_directory()
is non-local, I see no way to ensure that require for certain file
always happens with the same set of options. Of course, one can say
"composer and autoloading will ensure that" - but composer and its
autoloading, while undoubtedly popular, are libraries external to PHP,
and there's a lot of PHP code that is either not using composer, or
using composer in combination with other ways of autoloading. Unless we
mandate use of composer for every PHP project, this still does not solve
the issue.
And, of course, IDEs/analyzers would somehow have to figure this out too
- since composer.json is not actually defining the options (it is only
an input for declare_directory call sometime later) they'd probably have
to parse code and find declare_directory() calls? Or they'd just assume
everything in composer.json? What if I just manually call
declare_directory() then - would it break everything?

> 4. Specify declares in a special file, similar to how INI directives are
> declared. The suggestion here has been that PHP could scan the path of an
> included file upwards to find a declares.json (or similar).

This one at least ensures options for certain file are consistent, but
at the cost of introducing magic config files that PHP never had before,
and all complications coming with handling, caching and managing those
files (if declares.json changed, do you have to invalidate all opcode
caches for all files under this directory?).

> 5. Introduce a first-class module/package concept and support per-package
> declares. This is arguably the closest fit for what is needed, but also the
> most complex solution. This is a fairly big problem space and I personally
> do not want to pursue this outside a certain narrow scope.

That actually would be a workable solution if package semantics were
built into the language. That would ensure same code is always
associated with same options, allow compile-time handling of options and
would let IDEs, analyzers, etc. to have a consistent picture without
trying to parse runtime code. If I had to choose among the options here,
so far it's my favorite one, even though I recognize it may not be easy.

-- 
Stas Malyshev
smalyshev@gmail.com