On Sat, Jul 26, 2014 at 1:26 AM, Stas Malyshev <smalys...@sugarcrm.com> 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 than using Reflection for the same job. > > True but that's what phpunit, etc. are doing for mocks anyway, aren't they? > > > true, but it can also be used to argue for loosening the restriction, > > why restrict something from Reflection, which is already possible from > > simple class extension. > > I agree, probably makes sense to allow it if you can do it anyway. > Reflection is not something you can trigger without explicit codding > (unlike O: thing) so it's fine with me. > > > a nice thing from OOP POV and also will cause problems if/when we > > introduce a reflection method removing final from classes/methods (this > > was already proposed not that long ago with a working patch but was > > turned down because other reasons). > > That probably wouldn't be a good idea, especially for internal classes. Like I said in a previous mail, only Dom, Mysqli and sqlite3 need patch to be able to work with only create_object invoked. I'm not sure about COM as I can't setup a test environment for it. I recently started patching mysqli. I think it is feasable to have all of them patched so that newInstanceWithoutConstructor() may be safely "opened" to internal classes, for 5.6.0. A quick word as well to say I'm against giving the opportunity to userland to remove the final attribute, as this will lead to lots of bugs, some of them not even fixable I think. Julien.Pauli
