Re: [PHP-DEV] Re: Branch off PHP-7.4 early

On Thu, Jan 24, 2019 at 7:52 AM Nikita Popov wrote: > > On Fri, Nov 16, 2018 at 4:36 PM Sara Golemon wrote: > > > On Fri, Nov 16, 2018 at 9:26 AM Nikita Popov wrote: > > > I feel like there may be some understanding here, because what > > > is proposed here seems to match exactly what you propos

Re: [PHP-DEV] mbstring unused internal functions

On Thu, Jan 24, 2019 at 4:17 PM Legale Legage wrote: > Haven't checked php_mbregex.c > > This one is defined in mbstring.h but not exists in mbstring.c: > php_mb_check_encoding_list() > Thanks, dropped in https://github.com/php/php-src/commit/24085b187a7505aacb5bd76372f156656dd3 . > These

Re: [PHP-DEV] Re: Branch off PHP-7.4 early

Am 24.01.2019 um 15:52 schrieb Nikita Popov: * Create the PHP-7.4 branch now/soon, rather than in summer. * master will be PHP 8.0. * All changes are applied to the lowest applicable branch and then merged up as usual, including to PHP-7.4 and master. * NEWS mentions for bug fixes are only added

Re: [PHP-DEV] Re: Branch off PHP-7.4 early

On 24.01.2019 at 15:52, Nikita Popov wrote: > I'd like to bring this up again. Typed properties has been merged, so we > currently don't have any major code changes pending. To clarify what > exactly I'm proposing: > > * Create the PHP-7.4 branch now/soon, rather than in summer. > * master will

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

On Thu, 24 Jan 2019 at 15:06, wrote: > > Sorry, what I wanted to ask was, what happens if `__serialize()` and > `__SLEEP()` are implemented? xD > This is covered in the RFC: > If a class has both __sleep() and __serialize(), then the latter will be preferred. In other words, if both are includ

Re: [PHP-DEV] Re: Branch off PHP-7.4 early

On Thu, Jan 24, 2019 at 8:52 AM Nikita Popov wrote: > I'd like to bring this up again. Typed properties has been merged, so we > currently don't have any major code changes pending. To clarify what > exactly I'm proposing: > > * Create the PHP-7.4 branch now/soon, rather than in summer. > * mas

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

Sorry, forgot to CC the following mail to internals: Am 24-Jan-2019 14:28:43 +0100 schrieb nikita@gmail.com: > > On Thu, Jan 24, 2019 at 2:15 PM wrote: > > On Thu, Jan 24, 2019 at 13:27 Nikita Popov > > wrote: > > > > > Hi internals, > > > > > > I'd like to propose a new custom object ser

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

On Thu, 24 Jan 2019 at 14:53, Thomas Bley wrote: > To me it's not clear why we need all these methods, for example: > > $a = new A(); > $aSerialized = serialize($a->toArray()); > $aRestored = A::createFromArray(unserialize($aSerialized)); > > Apart from security problems, problems with versioning

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

Nikita Popov wrote on 24.01.2019 15:40: > On Thu, Jan 24, 2019 at 3:08 PM Larry Garfield > wrote: > >> On Thu, Jan 24, 2019, at 8:02 AM, Nicolas Grekas wrote: >> > Thank you Nikita, >> > >> > the RFC looks solid to me. Using magic methods makes perfect sense to >> allow >> > a smooth migration p

Re: [PHP-DEV] Re: Branch off PHP-7.4 early

On Fri, Nov 16, 2018 at 4:36 PM Sara Golemon wrote: > On Fri, Nov 16, 2018 at 9:26 AM Nikita Popov wrote: > > I feel like there may be some understanding here, because what > > is proposed here seems to match exactly what you proposed > > in your first mail to this thread. > > > Perhaps the impe

Re: [PHP-DEV] mbstring unused internal functions

On Thu, Jan 24, 2019 at 12:21 PM Legale Legage wrote: > Hello. > > Looking through the source code of the mbstring.c file I found a lot > of unused internal functions. It seems that this is just a bunch of > old junk. > > Examples: > > MBSTRING_API size_t php_mb_mbchar_bytes_ex(const char *s, con

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

On Thu, Jan 24, 2019 at 3:08 PM Larry Garfield wrote: > On Thu, Jan 24, 2019, at 8:02 AM, Nicolas Grekas wrote: > > Thank you Nikita, > > > > the RFC looks solid to me. Using magic methods makes perfect sense to > allow > > a smooth migration path. > > > > We could enforce that if one of __serial

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

Not really fussed about having another implicit interface for serialization (via magic methods). Wouldn't a new interface make this clear, explicit, and make the deprecation path easier (together with the migration)? Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Thu

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

On Thu, Jan 24, 2019, at 8:02 AM, Nicolas Grekas wrote: > Thank you Nikita, > > the RFC looks solid to me. Using magic methods makes perfect sense to allow > a smooth migration path. > > We could enforce that if one of __serialize() or __unserialize() is > > defined, both have to be defined, to a

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

Thank you Nikita, the RFC looks solid to me. Using magic methods makes perfect sense to allow a smooth migration path. We could enforce that if one of __serialize() or __unserialize() is > defined, both have to be defined, to avoid running into such cases. That would make sense a lot of sense t

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

On Thu, Jan 24, 2019 at 2:15 PM wrote: > On Thu, Jan 24, 2019 at 13:27 Nikita Popov > wrote: > > > Hi internals, > > > > I'd like to propose a new custom object serialization mechanism intended > to > > replace the broken Serializable interface: > > > > https://wiki.php.net/rfc/custom_object_ser

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

On Thu, Jan 24, 2019 at 13:27 Nikita Popov wrote: > Hi internals, > > I'd like to propose a new custom object serialization mechanism intended to > replace the broken Serializable interface: > > https://wiki.php.net/rfc/custom_object_serialization > > This was already previously discussed in h

[PHP-DEV] [RFC] New custom object serialization mechanism

Hi internals, I'd like to propose a new custom object serialization mechanism intended to replace the broken Serializable interface: https://wiki.php.net/rfc/custom_object_serialization This was already previously discussed in https://externals.io/message/98834, this just brings it into RFC form

[PHP-DEV] PHP 7.3.2RC1 is available for testing

Hi, PHP 7.3.2RC1 has just been released and can be downloaded from: Or use the git tag: php-7.3.2RC1 The Windows binaries are available at: Please test it carefully, and report any bugs in the bug system. 7.3.2 should be expect

[PHP-DEV] Re: mbstring unused internal functions

On 24.01.2019 at 12:20, Legale Legage wrote: > Looking through the source code of the mbstring.c file I found a lot > of unused internal functions. It seems that this is just a bunch of > old junk. > > Examples: > > MBSTRING_API size_t php_mb_mbchar_bytes_ex(const char *s, const > mbfl_encoding

Re: [PHP-DEV] Exposing the linux namespaces API via pcntl_*

On Wed, Jan 23, 2019 at 10:05 PM Rowan Collins wrote: > On 23/01/2019 21:15, Pedro Magalhães wrote: > > I think it can be useful for a language to expose this functionality to > the > > users for that kind of purpose (ie. run a security sensitive task in > > isolation, simulate certain conditions

[PHP-DEV] mbstring unused internal functions

Hello. Looking through the source code of the mbstring.c file I found a lot of unused internal functions. It seems that this is just a bunch of old junk. Examples: MBSTRING_API size_t php_mb_mbchar_bytes_ex(const char *s, const mbfl_encoding *enc) MBSTRING_API size_t php_mb_mbchar_bytes(const ch

HA: Re: [PHP-DEV] Proposal fo "Code-free constructors declaration"

I'm added an illustration. Maybe it more clear for understanding. https://wiki.php.net/_detail/rfc/joined.png?id=rfc%3Acode_free_constructor >> Proposed syntax >> class A($prop) extends B("BlaBla", $prop) { >> } > This looks like unobvious magic. PHP approach has traditionally been to > avoid uno