# [Discussion] Deprecate function sizeof() - Thread: https://externals.io/message/84403 - Original archive: https://news-web.php.net/php.internals/84403 - Started by reeze on 2015-03-07T15:51:41+00:00 - Messages: 18 - 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 --- ## #84403 — reeze — 2015-03-07T15:51:41+00:00 URL: https://externals.io/message/84403#84403 Hi internals, I'd like to deprecate function: `sizeof()` [1][2], which is an alias of `count()`. some people expect it return the memory size of the variable. The doc page's[1] user contributed notes indicate that too. What do you think? ---- [1] http://php.net/sizeof [2] https://github.com/php/php-src/pull/1161 [3] http://stackoverflow.com/questions/3974385/php-array-count-or-sizeof -- Reeze Xia http://reeze.cn --- ## #84406 — Kalle Sommer Nielsen — 2015-03-07T16:41:46+00:00 URL: https://externals.io/message/84403#84406 · In reply to: #84403 Hi 2015-03-07 16:51 GMT+01:00 reeze : > Hi internals, > > I'd like to deprecate function: `sizeof()` [1][2], which is an alias of > `count()`. some people > expect it return the memory size of the variable. > > The doc page's[1] user contributed notes indicate that too. > > What do you think? 'm a big -1 on this, while I know it returns the memory size in a C perspective, I think it makes perfect sense to remain an alias, it would break lots of applications for a very tiny to nothing gain. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #84409 — Sebastian B.-Hagensen — 2015-03-07T17:35:11+00:00 URL: https://externals.io/message/84403#84409 · In reply to: #84406 Hi, 2015-03-07 17:41 GMT+01:00 Kalle Sommer Nielsen : > I'm a big -1 on this, while I know it returns the memory size in a C > perspective, I think it makes perfect sense to remain an alias, it > would break lots of applications for a very tiny to nothing gain. I don't think the alias make sense and is really misleading and I've seen sizeof("abc"); often enough (Don't get me wrong that's equally bad with count, but sizeof encourages that usage, imo). Having two functions that do exactly the same using different names for no good reason (one of them referring to a different operation in a more popular language) isn't optimal. Code using a deprecated sizeof call is trivial to fix. But:. I'm not sure if the cost involved is really worth it, after all some big projects enforce sizeof over count and github returns over 1.2m results for sizeof+php (many false positives from html files documenting c code etc., still a huge number) . Random first two projects with over 500 stars/or big installation base I found: http://area51.phpbb.com/docs/31x/coding-guidelines.html#general : "Use sizeof instead of count" https://github.com/atoum/atoum/blob/master/CC.md#arrays : "To get length of an array, use sizeof instead of count (no technical reason about that, it's just the current convention)". On the other side: Removal of sizeof is doable with a patch release for almost all projects and shouldn't really require more than 5 to 10 minutes (+ time to review the diff) for most projects. --- ## #84410 — Lester Caine — 2015-03-07T17:43:57+00:00 URL: https://externals.io/message/84403#84410 · In reply to: #84409 > On the other side: Removal of sizeof is doable with a patch release > for almost all projects and shouldn't really require more than 5 to 10 > minutes (+ time to review the diff) for most projects. If taken in conjunction with tidying up the IEEE C standard consistency then dropping what is basically the wrong use of sizeof makes a lot of sense? Eventually using sizeof for the physical size of elements in line with it's C use would be more consistent. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #84413 — Kalle Sommer Nielsen — 2015-03-07T19:42:34+00:00 URL: https://externals.io/message/84403#84413 · In reply to: #84409 Hi 2015-03-07 18:35 GMT+01:00 Sebastian B.-Hagensen : > Hi, > I don't think the alias make sense and is really misleading and I've > seen sizeof("abc"); often enough (Don't get me wrong that's equally > bad with count, but sizeof encourages that usage, imo). > Having two functions that do exactly the same using different names > for no good reason (one of them referring to a different operation in > a more popular language) isn't optimal. Code using a deprecated sizeof > call is trivial to fix. Well we could make `count()`/sizeof() work for strings, so that if: C:\> php -r "echo sizeof('abc');" 3 although it would not really accomplish much imo., I think it is more of what background you come from that makes the most sense to me, I got into PHP before C and I enjoy sizeof more for array sizes than count, but that is just a pure preference. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #84414 — Bostjan Skufca — 2015-03-07T20:02:35+00:00 URL: https://externals.io/message/84403#84414 · In reply to: #84413 > Hi > > Well we could make `count()`/sizeof() work for strings, so that if: > C:\> php -r "echo sizeof('abc');" > 3 > > although it would not really accomplish much imo., I think it is more > of what background you come from that makes the most sense to me, I > got into PHP before C and I enjoy sizeof more for array sizes than > count, but that is just a pure preference. > Maybe `count()` and `sizeof()` should retain original functionality for the sake of compatibility, but should emit warning if used on non-array/object variables? This seems like a gentle way to steer users towards using `strlen()` on strings. Using sizeof(null) seems somewhat legitimate, but sizeof("asdf") seems like a newbie mistake at counting characters in a string. b. PS: All above assumes the functionality of `sizeof()` does not change. If `sizeof()` functionality should be changed to be more aligned with it's C counterpart, then above argument does not stand. --- ## #84415 — Stanislav Malyshev — 2015-03-07T20:41:43+00:00 URL: https://externals.io/message/84403#84415 · In reply to: #84403 Hi! > I'd like to deprecate function: `sizeof()` [1][2], which is an alias of > `count()`. some people > expect it return the memory size of the variable. Why? So, some people are wrong, why we need to mess with the language to accommodate them? I don't think it is a good idea. -- Stas Malyshev smalyshev@gmail.com --- ## #84423 — Yasuo Ohgaki — 2015-03-08T01:39:04+00:00 URL: https://externals.io/message/84403#84423 · In reply to: #84415 Hi all, On Sun, Mar 8, 2015 at 5:41 AM, Stanislav Malyshev wrote: > > […] > > Why? So, some people are wrong, why we need to mess with the language to > accommodate them? > I don't think it is a good idea. The same opinion. Unless there are good enough reasons, these aliases should be kept. If "Consistent function names" RFC passes, aliases will be listed in main function page only. It may reduce confusions hopefully. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #84447 — Pierre Joye — 2015-03-08T22:44:24+00:00 URL: https://externals.io/message/84403#84447 · In reply to: #84403 > Hi internals, > > I'd like to deprecate function: `sizeof()` [1][2], which is an alias of > `count()`. some people > expect it return the memory size of the variable. > > The doc page's[1] user contributed notes indicate that too. > > What do you think? As I tend to like the idea to cleanup things, adding warning and deprecation warnings for the sake of it is not too appealing to me. Especially for this kind of things. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #84451 — reeze — 2015-03-09T03:56:16+00:00 URL: https://externals.io/message/84403#84451 · In reply to: #84406 Hi, > Hi > > 2015-03-07 16:51 GMT+01:00 reeze : > > […] > > 'm a big -1 on this, while I know it returns the memory size in a C > perspective, I think it makes perfect sense to remain an alias, it > would break lots of applications for a very tiny to nothing gain. > It is a deprecated warning I won't break code I think. This could makes those project more maintainable (new PHP programmer could be easier to maintain the code without surprise), and it will be trivial to fix this. We could move things forward ;-) > > > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net > -- Reeze Xia http://reeze.cn --- ## #84452 — reeze — 2015-03-09T03:57:21+00:00 URL: https://externals.io/message/84403#84452 · In reply to: #84423 > Hi all, > > On Sun, Mar 8, 2015 at 5:41 AM, Stanislav Malyshev > wrote: > > > […] > > > The same opinion. Unless there are good enough reasons, these aliases > should be kept. If "Consistent function names" RFC passes, aliases will be > Yes, I think so, it didn't remove the alias, but propose use use `count()` instead. > listed in main function page only. It may reduce confusions hopefully. > That might helps. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > -- Reeze Xia http://reeze.cn --- ## #84453 — reeze — 2015-03-09T04:02:55+00:00 URL: https://externals.io/message/84403#84453 · In reply to: #84447 > > > […] > > As I tend to like the idea to cleanup things, adding warning and > deprecation warnings for the sake of it is not too appealing to me. > Especially for this kind of things. > Yes it will not really fix the confusion, and it is a small problem, I know few decent projects use sizeof, we could make the old code involve and more consist. `sizeof()` was kept because of BC since PHP4.0, `count()` should be the recommended function. > > Cheers, > -- > Pierre > > @pierrejoye | http://www.libgd.org > -- Reeze Xia http://reeze.cn --- ## #84492 — Yasuo Ohgaki — 2015-03-10T02:07:16+00:00 URL: https://externals.io/message/84403#84492 · In reply to: #84451 Hi Reeze, > It is a deprecated warning I won't break code I think. > > This could makes those project more maintainable (new PHP programmer could > be easier to maintain the code without surprise), and it will be trivial to > fix this. We could move things forward ;-) > It's possible option for confusing APIs. If `sizeof()` is kept at least until PHP8 or PHP9, I'll vote yes for this. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #84494 — Xinchen Hui — 2015-03-10T02:48:11+00:00 URL: https://externals.io/message/84403#84494 · In reply to: #84492 Hey: > Hi Reeze, > > > > > […] > > It's possible option for confusing APIs. > If `sizeof()` is kept at least until PHP8 or PHP9, I'll vote yes for this. We just removed all DEPRECATED functions... then you want to brings new :< anyway, I'd prefer don't do it. especially with little gain. thanks > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #84495 — Pierre Joye — 2015-03-10T02:59:02+00:00 URL: https://externals.io/message/84403#84495 · In reply to: #84494 > Hey: > > > > […] > We just removed all DEPRECATED functions... we did not remove functions as far as I can tell. Some extension at best. > then you want to brings new :< > > anyway, I'd prefer don't do it. especially with little gain. Agreed And generally speaking, we should really think again about this flag, it has been proven to be a mess at best, or useless at worst. -- Pierre @pierrejoye | http://www.libgd.org --- ## #84497 — Yasuo Ohgaki — 2015-03-10T03:41:07+00:00 URL: https://externals.io/message/84403#84497 · In reply to: #84495 Hi Pierre and all, > > > […] > wrote: > > […] > could > > […] > trivial to > > […] > > we did not remove functions as far as I can tell. Some extension at best. > > > […] > > Agreed > > And generally speaking, we should really think again about this flag, > it has been proven to be a mess at best, or useless at worst. There are 2 camps, people who would like to keep procedural API as it is and people who would like to improve/maintain procedural API while there are no separated camps having improved/maintained OO API. It may be time to discuss how we are going to use namespace for internal functions/classes/interfaces to move forward both procedural and OO APIs so that we'll have zero BC API upgrade. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #84498 — Pierre Joye — 2015-03-10T06:54:52+00:00 URL: https://externals.io/message/84403#84498 · In reply to: #84497 > > Hi Pierre and all, > > On Tue, Mar 10, 2015 at 11:59 AM, Pierre Joye wrote: > > […] wrote: > > […] could > > […] trivial to > > […] this. > > […] > > > There are 2 camps, people who would like to keep procedural API as it is > and people who would like to improve/maintain procedural API while there > are no separated camps having improved/maintained OO API. > > It may be time to discuss how we are going to use namespace for internal > functions/classes/interfaces to move forward both procedural and OO APIs > so that we'll have zero BC API upgrade. I do not think it has anything to do with OO or procedural but the actual gains. I see none here. > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net --- ## #84518 — Yasuo Ohgaki — 2015-03-10T20:30:51+00:00 URL: https://externals.io/message/84403#84518 · In reply to: #84498 Hi Pierre, > I do not think it has anything to do with OO or procedural but the actual > gains. > > I see none here. > Why not? PHP is distributed with set of APIs. i.e. Libraries. Tight binding with libraries and language make library update difficult . Besides zero BC, it seems it's time to introduce namespaces for internal features. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net