Re: [PHP-DEV] [RFC] New custom object serialization mechanism
On Sun, Jan 27, 2019 at 5:37 PM Nicolas Grekas wrote: > Le jeu. 24 janv. 2019 à 15:18, Sebastian Bergmann a > écrit : > > > Am 24.01.2019 um 15:09 schrieb Marco Pivetta: > > > Not really fussed about having another implicit interface for > > serialization > > > (via magic methods). > > > > I second that emotion. > > > > > The more I think about it, the more I'm convinced we should *not* add an > interface for that. > An interface defines a semantics - something that an API tpoa domain and > that ppl can type-hint for to get a specific implementation of that > API. An interface declares an API surface for an object: in this case, the consumer would be `serialize()` or `unserialize()`, and that's a perfectly valid use-case scenario. > Here, both aspects are not desired: we don't want ppl to type-hint for > e.g. Serializable - and too bad it exists because I've already seen ppl > think: "hey, I'll type-hint or extend it to express I want a serializable > thing". That's actually a very correct thing to do: by declaring that something is `Serializable`, you are expressing your intent to anybody inspecting the structure of the object. > BUT that's *not* the contract of Serializable or any variant of it > because: 1. *any* PHP object is serializable 2. Serializable it well > allowed to throw an exception to exactly *forbid* an object from being > serialized. > That's a completely different problem, which is that PHP has no way to declare APIs as functionally pure, or exception-less. That's something to be explored, in my opinion, but the lack of it does not warrant dismissing interfaces altogether (your current argument). Serializability is something to be declared: currently, PHP is very much ill-designed on this particular scope, but that doesn't mean that we should make it even worse. >From this reasoning, I conclude that we really want magic methods here > because what we need is a *behavior*. We want to hook into the engine to > benefit from some special features it provides. That's what all magic > methods are about and hooking into serialize()/unserialize() is not > different. > Yet more magic methods just add an impressive amount of complexity to the language (I'm already thinking of the permutations of edge cases that I'm personally going to have to write). It's yet another way to define something that would work correctly if an interface (existing mechanism defined by the language) was used instead. Magic methods would just provide that, without polluting the semantics > space. > The newly introduced magic methods pollute the entire **language semantics**: now you have another edge case in the language, instead of an interface that works in combination with the `serialize()` and `unserialize()` functions. I'll also add that the problem being solved is much smaller than the issues introduced by the proposed additions. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] 7.3.1 corruption issue
On 1/27/19 4:57 PM, Alice Wonder wrote: I can't file a bug report because I do not know what went run. I only know system php 7.3.1 Site suddenly stopped working. Apache error log says: Mon Jan 28 00:45:17.896727 2019] [php7:error] [pid 4117:tid 140287279617792] [client 73.15.182.232:53028] PHP Fatal error: require_once(): Failed opening required 'base.inc.php' (include_path='.:/usr/share/pear:/usr/share/php') in /srv/[redacted]/www/controller.php on line 2 That include path is interesting, it lists /usr/share/pear:/usr/share/php I set the include path in Apache config: Options FollowSymlinks AllowOverride All Require all granted php_value include_path "/srv/[redacted]/phpinclude:/usr/share/pear" AddType application/x-httpd-php-source .phps I never set include path in my php code. It looks like the value became corrupted and so it went to a default. Restarted Apache and everything worked. How would I find out what corrupted that setting? That sounds dangerous. Never happened in php 7.1.x which I ran from start, or in 7.3.0 which I also ran from the start. Memory corruption bug? correction, it reverted to .:/usr/share/pear:/usr/share/php which is dangerous, php should not have a default that includes the directory the script is running from even though a lot of people like to do that. When a path is explicitly set to NOT include the current directory, including it in a default when the setting becomes corrupt could (should?) be considered a security flaw. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 7.3.1 corruption issue
I can't file a bug report because I do not know what went run. I only know system php 7.3.1 Site suddenly stopped working. Apache error log says: Mon Jan 28 00:45:17.896727 2019] [php7:error] [pid 4117:tid 140287279617792] [client 73.15.182.232:53028] PHP Fatal error: require_once(): Failed opening required 'base.inc.php' (include_path='.:/usr/share/pear:/usr/share/php') in /srv/[redacted]/www/controller.php on line 2 That include path is interesting, it lists /usr/share/pear:/usr/share/php I set the include path in Apache config: Options FollowSymlinks AllowOverride All Require all granted php_value include_path "/srv/[redacted]/phpinclude:/usr/share/pear" AddType application/x-httpd-php-source .phps I never set include path in my php code. It looks like the value became corrupted and so it went to a default. Restarted Apache and everything worked. How would I find out what corrupted that setting? That sounds dangerous. Never happened in php 7.1.x which I ran from start, or in 7.3.0 which I also ran from the start. Memory corruption bug? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simplify license headers
On Sun, 27 Jan 2019 at 20:39, Nikita Popov wrote: > > Hi internals, > > Some of our source files currently contain a license header similar to this: > > /* > +--+ > | PHP Version 7 | > +--+ > | Copyright (c) 1997-2018 The PHP Group | > +--+ > | This source file is subject to version 3.01 of the PHP license, | > | that is bundled with this package in the file LICENSE, and is | > | available through the world-wide-web at the following url: | > | http://www.php.net/license/3_01.txt | > | If you did not receive a copy of the PHP license and are unable to | > | obtain it through the world-wide-web, please send a note to | > | lice...@php.net so we can mail you a copy immediately. | > +--+ > | Authors: Andi Gutmans | > | Zeev Suraski | > +--+ > */ > > I would like to make two changes to this header: > > 1. Change "PHP Version 7" line to just "PHP", to avoid the necessity of > updating this for new major versions. I don't think the version information > here is particularly useful to anybody. > > 2. Remove the "Copyright (c) 1997-2018 The PHP Group" line. Apart from > requiring a yearly update, this line is actually complete misinformation, > because the PHP group does *not* hold the copyright for the PHP source > code. This would require a copyright assignment agreement on behalf of all > contributors, which we do not collect. > > We could also just drop the header entirely, I'm just proposing these two > changes as the path of least resistance towards getting the "annoying" > parts removed. > > Regards, > Nikita And maybe also additional change from: http://www.php.net/license/3_01.txt to https short link that points to license content as well: https://php.net/license/3_01.txt -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simplify license headers
I think author's name on each file is good practice. Once i used this information. IMHO the shortest header is the nicest one.On Jan 27, 2019 20:38, Nikita Popov wrote: > > Hi internals, > > Some of our source files currently contain a license header similar to this: > > /* > +--+ > | PHP Version 7 | > +--+ > | Copyright (c) 1997-2018 The PHP Group | > +--+ > | This source file is subject to version 3.01 of the PHP license, | > | that is bundled with this package in the file LICENSE, and is | > | available through the world-wide-web at the following url: | > | http://www.php.net/license/3_01.txt | > | If you did not receive a copy of the PHP license and are unable to | > | obtain it through the world-wide-web, please send a note to | > | lice...@php.net so we can mail you a copy immediately. | > +--+ > | Authors: Andi Gutmans | > | Zeev Suraski | > +--+ > */ > > I would like to make two changes to this header: > > 1. Change "PHP Version 7" line to just "PHP", to avoid the necessity of > updating this for new major versions. I don't think the version information > here is particularly useful to anybody. > > 2. Remove the "Copyright (c) 1997-2018 The PHP Group" line. Apart from > requiring a yearly update, this line is actually complete misinformation, > because the PHP group does *not* hold the copyright for the PHP source > code. This would require a copyright assignment agreement on behalf of all > contributors, which we do not collect. > > We could also just drop the header entirely, I'm just proposing these two > changes as the path of least resistance towards getting the "annoying" > parts removed. > > Regards, > Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Simplify license headers
Hi internals, Some of our source files currently contain a license header similar to this: /* +--+ | PHP Version 7 | +--+ | Copyright (c) 1997-2018 The PHP Group | +--+ | This source file is subject to version 3.01 of the PHP license, | | that is bundled with this package in the file LICENSE, and is | | available through the world-wide-web at the following url: | | http://www.php.net/license/3_01.txt | | If you did not receive a copy of the PHP license and are unable to | | obtain it through the world-wide-web, please send a note to | | lice...@php.net so we can mail you a copy immediately. | +--+ | Authors: Andi Gutmans | | Zeev Suraski | +--+ */ I would like to make two changes to this header: 1. Change "PHP Version 7" line to just "PHP", to avoid the necessity of updating this for new major versions. I don't think the version information here is particularly useful to anybody. 2. Remove the "Copyright (c) 1997-2018 The PHP Group" line. Apart from requiring a yearly update, this line is actually complete misinformation, because the PHP group does *not* hold the copyright for the PHP source code. This would require a copyright assignment agreement on behalf of all contributors, which we do not collect. We could also just drop the header entirely, I'm just proposing these two changes as the path of least resistance towards getting the "annoying" parts removed. Regards, Nikita
Re: [PHP-DEV] [RFC] New custom object serialization mechanism
Le jeu. 24 janv. 2019 à 15:18, Sebastian Bergmann a écrit : > Am 24.01.2019 um 15:09 schrieb Marco Pivetta: > > Not really fussed about having another implicit interface for > serialization > > (via magic methods). > > I second that emotion. > The more I think about it, the more I'm convinced we should *not* add an interface for that. An interface defines a semantics - something that an API tpoa domain and that ppl can type-hint for to get a specific implementation of that API.Here, both aspects are not desired: we don't want ppl to type-hint for e.g. Serializable - and too bad it exists because I've already seen ppl think: "hey, I'll type-hint or extend it to express I want a serializable thing". BUT that's *not* the contract of Serializable or any variant of it because: 1. *any* PHP object is serializable 2. Serializable it well allowed to throw an exception to exactly *forbid* an object from being serialized. >From this reasoning, I conclude that we really want magic methods here because what we need is a *behavior*. We want to hook into the engine to benefit from some special features it provides. That's what all magic methods are about and hooking into serialize()/unserialize() is not different. The parallel with the Symfony Serializer is interesting but it stop here: we don't need any help from core to build it. We should not seek for that goal IMHO as it blur the lines of what we're needing: a core primitive to build more useful things. Magic methods would just provide that, without polluting the semantics space. My 2cts, Nicolas
Re: [PHP-DEV] Local variables for editors
Hello, On Tue, 22 Jan 2019 at 16:49, Levi Morrison wrote: > > On Wed, Nov 29, 2017 at 2:54 PM Peter Kokot wrote: > > > > Hello, > > > > I'm not sure if this has been discussed before, but I find these local > > variables in C, H and other files a bit strange and bloated: > > > > /* > > * Local variables: > > * tab-width: 4 > > * c-basic-offset: 4 > > * End: > > * vim600: noet sw=4 ts=4 fdm=marker > > * vim<600: noet sw=4 ts=4 > > */ > > > > Is there any chance to start omitting them and use a single > > .editorconfig file instead or is this something that is a must have in > > C projects of today? > > > > Thank you for some clarification on this :) > > -- > > Peter Kokot > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > I use vim, and do not enable these per-file settings. I don't think > any distributions enable them by default either. My opinion: I think > we can get rid of them. > > I have used .editorconfig and .clang-tidy for other projects and liked > it. I tried using it with tabs, and the experience seemed less > polished but still worked. Thank you for both feedback. There is a pull request [1] prepared to remove these. It is split into several commits that did these in multiple steps for easier reviewing. Changes: - All footers (local variables blocks) removed since they don't provide anything drastically useful in most editors with default settings - Removed the so called Vim modeline in some *.phpt files to set the PHP syntax highlighting, because this functionality for *.phpt files specifically is not important. Most editors show the PHP syntax by default already neither the modelines wer synced across all of phpt files. For example // vim600: syn=php - The ext/ext_skel.php script also adjusted to not generate the footer with local variables. I have left two local variables/modelines: - in *.w32 files the modeline sets the syntax highlighting in some editors and on GitHub also: // vim:ft=javascript - In certain *.phpt files the modeline sets encodings which probably also don't work properly everywhere but for the documentation purposes I've left those in for now // vim: set encoding=cp936 Hoping that EditorConfig will also get improved with additional features over time here a bit. So, that's good to go in master branch in the next days? If not, let me know... Cheers. [1] https://github.com/php/php-src/pull/3757 -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
