# [Patches]#36944, #54556, #55211(and svn karma applying) - Thread: https://externals.io/message/54189 - Original archive: https://news-web.php.net/php.internals/54189 - Started by Laruence on 2011-07-25T11:57:03+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #54189 — Laruence — 2011-07-25T11:57:03+00:00 URL: https://externals.io/message/54189#54189 Hi: recently I was working on PHP bugs. and submit 3 patches, #36944 strncmp & negative len https://bugs.php.net/bug.php?id=36944 #54556 array access to empty var does not trigger a notice https://bugs.php.net/bug.php?id=54556 #55211 ArrayObject::getArrayObject () should skip proteced or private properties https://bugs.php.net/bug.php?id=55211 someone plz verify them. thanks and by the way, can I earn svn karma for PHP src now? I also submitted #54347 reflection_extension does not lowercase module function name #52935 call exit in user_error_handler cause stream relate core and one rfc: https://wiki.php.net/rfc/foreachlist and one pecl: http://pecl.php.net/package/Yaf if the karma approved, I promise I will work harder, and observe all existing rules. but it's okey if that you think I am not ready for a PHP src karma, we can talk this later. :) thanks -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #54195 — Laruence — 2011-07-26T05:42:50+00:00 URL: https://externals.io/message/54189#54195 · In reply to: #54189 Hi: new patch: #55128 SplFixedArray::fromArray() does not use extended class thanks 2011/7/25 Laruence : > Hi: >    recently I was working on PHP bugs. > >    and  submit 3 patches, > >    #36944      strncmp & negative len https://bugs.php.net/bug.php?id=36944 >    #54556  array access to empty var does not trigger a notice > https://bugs.php.net/bug.php?id=54556 >    #55211  ArrayObject::getArrayObject () should skip proteced or > private properties https://bugs.php.net/bug.php?id=55211 > >    someone plz verify them. thanks > >    and by the way,  can I earn svn karma for PHP src now? > >    I also submitted >          #54347        reflection_extension does not lowercase module function name >          #52935        call exit in user_error_handler cause stream relate core > >    and one rfc: >          https://wiki.php.net/rfc/foreachlist > >    and one pecl: >          http://pecl.php.net/package/Yaf > >   if the karma  approved, I promise I will work harder, and observe > all existing rules. > >   but it's okey if that you think I am not ready for a PHP src karma, > we can talk this later. :) > > thanks > > -- > Laruence  Xinchen Hui > http://www.laruence.com/ > -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #54205 — Gustavo Lopes — 2011-07-26T09:06:44+00:00 URL: https://externals.io/message/54189#54205 · In reply to: #54195 Em Tue, 26 Jul 2011 06:42:50 +0100, Laruence escreveu: > 2011/7/25 Laruence : > > […] Looks good, but I didn't got through it thoroughly to check the consistency of the signs. > > […] Won't this be affected? > […] Looks good. > > #55128 SplFixedArray::fromArray() does not use extended class This doesn't look like a good idea. The constructor is not called (and in general can't be, since we can't know how the subclass constructor looks like), so the new object can be in an illegal state. -- Gustavo Lopes --- ## #54208 — Laruence — 2011-07-26T11:14:15+00:00 URL: https://externals.io/message/54189#54208 · In reply to: #54205 2011/7/26 Gustavo Lopes : > Em Tue, 26 Jul 2011 06:42:50 +0100, Laruence escreveu: > > > […] > > Looks good, but I didn't got through it thoroughly to check the consistency > of the signs. > > > […] > > Won't this be affected? > > $foo[] = 'bar'; > no, this situation won't be affected > I don't see a good reason for this not to be allowed. > > > […] > > Looks good. > > > […] > > This doesn't look like a good idea. The constructor is not called (and in > general can't be, since we can't know how the subclass constructor looks > like), so the new object can be in an illegal state. > After much thought, I think there maybe no reason for fixedarray extended class to define it's own constructor, since we provide fixedarrary::__construct and fromArray already, and extended class should only get an instance through calling them. so I think we can make fixedarray::__construct final to make this feature works. > -- > Gustavo Lopes > > -- > > > > thanks -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #54209 — Gustavo Lopes — 2011-07-26T11:31:07+00:00 URL: https://externals.io/message/54189#54209 · In reply to: #54208 Em Tue, 26 Jul 2011 12:14:15 +0100, Laruence escreveu: > 2011/7/26 Gustavo Lopes : > > […] > no, this situation won't be affected Ah, if this is only for read situations, a notice seems appropriate. > > […] > After much thought, I think there maybe no reason for fixedarray > extended class to define it's own constructor, since we provide > fixedarrary::__construct and fromArray already, and extended class > should only get an instance through calling them. > > so I think we can make fixedarray::__construct final to make this > feature works. I disagree. Besides being a BC break, there's no good reason to make the constructor final and it has the disadvantage of severely limiting the subclasses. Instead of using LSB, I think a better option would be to provided a protected final instance method that would do this special form of initialization from an array. Subclasses could then write their own static method (possibly with the same name) for initializing from an array or even accept an array as a constructor argument. This is a bit more work and less magic than LSB, but much more versatile. -- Gustavo Lopes