On Tue, Jul 29, 2014 at 9:48 AM, Stas Malyshev
wrote:
> Hi!
>
> > What I found *not safe*, throwing unwanted warnings hitting an
> > undesired behavior, or even segfaulting, and thus needing patch :
> > - Dom
> > - Mysqli
> > - sqlite3 (sqlite3stmt class segfaults)
>
> I've fixed all the instanc
Hi!
> What I found *not safe*, throwing unwanted warnings hitting an
> undesired behavior, or even segfaulting, and thus needing patch :
> - Dom
> - Mysqli
> - sqlite3 (sqlite3stmt class segfaults)
I've fixed all the instances of problematic behavior with no ctor that I
could catch now. I could
Hi!
> It would be good to have a section in UPGRADING.INTERNALS explaining
> in details what should be done, very important for non core extensions
> (pecl or other repositories).
Probably a good idea but I'm not sure what exactly to write there,
besides "initialize everything, check everything"
hi,
On Sun, Jul 27, 2014 at 1:59 AM, Stas Malyshev wrote:
> Hi!
>
>> What I found *safe*, with checkers that check object is properly
>> initialized, so not needing patch, but throwing exceptions or warnings
>> when used bad constructed :
>> - SPL
>
> SPL unfortunately is not safe at all - a lot
Hi!
> What I found *safe*, with checkers that check object is properly
> initialized, so not needing patch, but throwing exceptions or warnings
> when used bad constructed :
> - SPL
SPL unfortunately is not safe at all - a lot of iterator classes
segfault on no-ctor initialization. I'll make a pa
Hi!
> What I found *not safe*, throwing unwanted warnings hitting an
> undesired behavior, or even segfaulting, and thus needing patch :
> - Dom
> - Mysqli
> - sqlite3 (sqlite3stmt class segfaults)
I'm testing a patch for sqlite3 right now and will commit it shortly,
but I could not reproduce an
Hi!
> nope, some mock frameworks do that (afair atoum for example) but
> phpunit(phpunit-mock-objects to be more precise) was using the serialize
> trick and newInstanceWithoutConstructor()
> (https://github.com/sebastianbergmann/phpunit-mock-objects/blob/42f29d650744fd7ce785e7a4dd3598a09b0bfd2b/s
On Sat, Jul 26, 2014 at 1:26 AM, Stas Malyshev
wrote:
> Hi!
>
> > yeah, that would work ofc, but as these libs seems to have instanitate
> > arbitrary classes, that would require either generating files on the fly
> > and including them or simply evaling them, but of those are a bit
> > dirtier
On Sat, Jul 26, 2014 at 9:55 PM, Julien Pauli wrote:
> On Sat, Jul 26, 2014 at 1:26 AM, Stas Malyshev
> wrote:
>
>> Hi!
>>
>> > yeah, that would work ofc, but as these libs seems to have instanitate
>> > arbitrary classes, that would require either generating files on the fly
>> > and including
On Sat, Jul 26, 2014 at 1:26 AM, Stas Malyshev
wrote:
> Hi!
>
> > yeah, that would work ofc, but as these libs seems to have instanitate
> > arbitrary classes, that would require either generating files on the fly
> > and including them or simply evaling them, but of those are a bit
> > dirtier
Hi!
> yeah, that would work ofc, but as these libs seems to have instanitate
> arbitrary classes, that would require either generating files on the fly
> and including them or simply evaling them, but of those are a bit
> dirtier than using Reflection for the same job.
True but that's what phpun
On Sat, Jul 26, 2014 at 12:29 AM, Stas Malyshev
wrote:
> Hi!
>
> > client) I see no reason to keep the limitation in
> > the ReflectionClass::newInstanceWithoutConstructor() and allowing the
> > instantiation of internal classes will provide a clean upgrade path to
> > doctrine and co.
>
> I thin
Hi!
> client) I see no reason to keep the limitation in
> the ReflectionClass::newInstanceWithoutConstructor() and allowing the
> instantiation of internal classes will provide a clean upgrade path to
> doctrine and co.
I think we should ensure the objects will be in safe (i.e. no-crashing)
state
On Wed, Jul 23, 2014 at 11:12 AM, Julien Pauli wrote:
> On Wed, Jul 23, 2014 at 11:09 AM, Ferenc Kovacs wrote:
>>
>>
>>
>> On Wed, Jul 23, 2014 at 10:57 AM, Julien Pauli wrote:
>>>
>>> On Wed, Jul 23, 2014 at 7:58 AM, Ferenc Kovacs wrote:
>>> >
>>> >
>>> >
>>> > On Tue, Jul 22, 2014 at 6:20 PM,
On Wed, Jul 23, 2014 at 11:09 AM, Ferenc Kovacs wrote:
>
>
>
> On Wed, Jul 23, 2014 at 10:57 AM, Julien Pauli wrote:
>>
>> On Wed, Jul 23, 2014 at 7:58 AM, Ferenc Kovacs wrote:
>> >
>> >
>> >
>> > On Tue, Jul 22, 2014 at 6:20 PM, Julien Pauli wrote:
>> >>
>> >> On Tue, Jul 22, 2014 at 2:04 PM,
On Wed, Jul 23, 2014 at 10:57 AM, Julien Pauli wrote:
> On Wed, Jul 23, 2014 at 7:58 AM, Ferenc Kovacs wrote:
> >
> >
> >
> > On Tue, Jul 22, 2014 at 6:20 PM, Julien Pauli wrote:
> >>
> >> On Tue, Jul 22, 2014 at 2:04 PM, Ferenc Kovacs
> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, Jul 22, 2014
On Wed, Jul 23, 2014 at 7:58 AM, Ferenc Kovacs wrote:
>
>
>
> On Tue, Jul 22, 2014 at 6:20 PM, Julien Pauli wrote:
>>
>> On Tue, Jul 22, 2014 at 2:04 PM, Ferenc Kovacs wrote:
>> >
>> >
>> >
>> > On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov
>> > wrote:
>> >>
>> >> On Tue, Jul 22, 2014 at 12:27
On Tue, Jul 22, 2014 at 6:20 PM, Julien Pauli wrote:
> On Tue, Jul 22, 2014 at 2:04 PM, Ferenc Kovacs wrote:
> >
> >
> >
> > On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov
> wrote:
> >>
> >> On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs
> wrote:
> >>>
> >>> sorry for the late reply.
> >>> you
On Tue, Jul 22, 2014 at 2:04 PM, Ferenc Kovacs wrote:
>
>
>
> On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov wrote:
>>
>> On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs wrote:
>>>
>>> sorry for the late reply.
>>> you are right and after looking into the implementation I think classes
>>> having
On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov wrote:
> On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs wrote:
>
>> sorry for the late reply.
>> you are right and after looking into the implementation I think classes
>> having custom object storage (eg. create_object) shouldn't assume that
>> the
On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs wrote:
> sorry for the late reply.
> you are right and after looking into the implementation I think classes
> having custom object storage (eg. create_object) shouldn't assume that
> their __construct will be called, but either do the initializatio
On Mon, Jun 30, 2014 at 8:10 PM, Alexey Zakhlestin
wrote:
>
> On 30 Jun 2014, at 11:10, Stas Malyshev wrote:
>
> > I think we should move away from the practice of using serializer for
> > something it was never made for, namely a weird way of instantiating
> > classes. Serializer should be work
22 matches
Mail list logo
