> Le 28 janv. 2019 à 08:58, Marco Pivetta a écrit :
>
>>
>> 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".
Den 2019-01-24 kl. 15:09, skrev Marco Pivetta:
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)?
How important is the
(I should have reviewed myself in the first message - sentences edited in
this reply)
Le lun. 28 janv. 2019 à 08:58, Marco Pivetta a écrit :
> On Sun, Jan 27, 2019 at 5:37 PM Nicolas Grekas <
> nicolas.grekas+...@gmail.com> wrote:
>
>> Le jeu. 24 janv. 2019 à 15:18, Sebastian Bergmann a
>>
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
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
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
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
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
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
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
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
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
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
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
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:
> >
> >
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
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
17 matches
Mail list logo
