# A critique of PHP 6 - Thread: https://externals.io/message/48023 - Original archive: https://news-web.php.net/php.internals/48023 - Started by Adi Nita on 2010-04-20T14:39:07+00:00 - Messages: 21 - 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 --- ## #48023 — Adi Nita — 2010-04-20T14:39:07+00:00 URL: https://externals.io/message/48023#48023 Hi everyone, Regarding some of the features that are going to ship in PHP 6, I'm going to take some liberty and make some personal remarks in the form of positive criticism. 1. SYSTEM NAMESPACES. There are many PHP built-in functions that act on certain groups of entities. The best examples are the *array_** and *str* *functions. There are many of them, and it gets really cumbersome to repeat the same prefix for each and every one. This is clearly a reminiscence of original procedural-style PHP. But now we have namespaces, that were introduced exactly for this kind of situations. Why not take advantage of it? PHP can have a built-in *\std\array* or *\php\array* or *\__array* namespace that would group all functions related to arrays, and thus have the *array_*prefix removed. I see this as an elegant solution for grouping functionality, without the use of classes and objects as some languages do to solve this issue. Also, as namespaces support *const* values, they can easily be employed here and have some of their prefixes removed too. Moreover, I see this extended to certain extensions as well, such as the database extension. Because, let's face it, it's not that logical to have a *mysqli* class and objects of type *mysqli.* It would make more sense to have *mysql, mysqli, mssql, oracle *(not *oci8*), *sqlite* etc. namespaces from a logical (and realistic) point of view. What I want to emphasize is: Let's not use classes and repetitive prefixes for grouping purposes, especially when we have a dedicated language feature for that. 2. TYPE HINTING. Currently PHP supports argument type hinting for arrays and objects. As I know, it's also been decided to offer support for this in function return values. For me it is hard to understand why not offer support for type hinting of scalar values as well. Hinting *string*, *int*, *float* and *bool* values can save a lot of debugging time and would provide a great mechanism for early detection of bugs. It will also allow developers to avoid writing hundreds of lines of code (with *is_type *tests) in a medium application just to ensure their parameters are of the expected type. It's better and faster to have checks at compile time. I cannot agree with the phrase "We do not allow type-hinted properties as it's not the PHP way". But what is the PHP way? Classes and namespaces were not the PHP way either. Here we have (and use) them. PHP needs type-hinted object properties just as it needs type-hinted function arguments. It will reduce a lot of errors and bugs in code that logically requires some properties to be of a certain type. It will make objects more consistent. It will make interfaces more intuitive and more semantic. And the time spent by the compiler to make the checks will be a better tradeoff than have lots of lines of application code testing for types. It's logical for a Person to have a *string* name, an *int* age, a *bool* gender and so on. I believe this is the PHP way. 3. CONST VALUES. PHP supports class constants and, as of 5.3, namespace constants with the same syntax. However, there is a major limitation upon constants: "The value must be a constant expression, not (for example) a variable, a property, a result of a mathematical operation, or a function call". I think PHP makes a faulty use of constants throughout its implementation. We have original constants (can be *define*'d even with non-constant expressions), class and namespace constants (can have only constant-expression values) and the so-called magic constants that... are not really constants at all. Generally, constants are language elements that are defined with an initial value and cannot be reassigned or redefined later. It's an improper use of "initial value" as this is their only value. There should be no restriction upon where their value comes from, as long as you cannot change it later on. In PHP this limitation comes from the fact that constants are resolved at compile time, rather than run time. However, I think it should be possible to have constant arrays as their values, just as we have them in object properties. Also, as with the introduction of namespaces, the non-namespaced code coincides with the global namespace ( \ ) code, I think it's safe to remove the *define* function and possibly allow the *const *keyword to define runtime constants as well (when the value is not a constant expression). 4. PARAMETER ORDER. As noted in an older PHP meeting: *We went over the string functions and found that there are only two functions that have "needle, haystack" instead of "haystack, needle", namely `in_array()` and `array_search()`. For `in_array()` it makes sense in a logical way to work in the same way as SQL, where you first specify the value, and then you check if it fits "in the array". As `array_search()` was modelled on this `is_array()` function the parameter order is the same. As there are not many inconsistencies, and changing them would cause quite some problems for current applications we decided not to change the order.* The conclusion here is a bit disappointing. We have the chance to fix a problem, but we choose not to. The very fact that there are *only two*functions with an inconsistent parameter order is a *real reason *to make the change. What if a third of the functions were inconsistent, would we make the change more easily? I doubt it, and at the same time I am convinced that it is much better to have things fixed earlier and before it's too late. _____________ These were the major issues that came to my mind until now. I am sure many things and ideas can be rejected with the reason of backward compatibility and fear of breaking tons of lines of ancient code. But existing code can and has to be rewritten, modified or maintained in order to keep the pace. I'm totally against the idea that PHP should keep the pace with old code, and against the idea of an unbreakable constant-expression PHP style. This is a dynamic language and should act like one. Developers expect it to change for the better, and not just add up features. I hope I didn't sound too harsh :-), I really appreciate all the hard work that has been put into the development of PHP 5.3, as I use it quite heavily. I like seeing intuitive and efficient (not just productive) features added, the same way I want bad features taken out. Sorry for any features that are planned for implementation and that I'm not aware of. Thank you for your time, Adrian Nita --- ## #48024 — Alain Williams — 2010-04-20T14:52:04+00:00 URL: https://externals.io/message/48023#48024 · In reply to: #48023 > Hi everyone, > > Regarding some of the features that are going to ship in PHP 6, I'm going to > take some liberty and make some personal remarks in the form of positive > criticism. > > 1. SYSTEM NAMESPACES. There are many PHP built-in functions that act on > certain groups of entities. The best examples are the *array_** and > *str* *functions. > There are many of them, and it gets really cumbersome to repeat the same > prefix for each and every one. This is clearly a reminiscence of original > procedural-style PHP. But now we have namespaces, that were introduced > exactly for this kind of situations. Why not take advantage of it? PHP can > have a built-in *\std\array* or *\php\array* or *\__array* namespace that > would group all functions related to arrays, and thus have the > *array_*prefix removed. I see this as an elegant solution for grouping > functionality, without the use of classes and objects as some languages do > to solve this issue. Also, as namespaces support *const* values, they can > easily be employed here and have some of their prefixes removed too. I think that that would be a bad idea - cause endless confusion. Coders copy code between files, you will have code written with some prefix in mind going into code with a different prefix - and doing something completely different. > Moreover, I see this extended to certain extensions as well, such as the > database extension. Because, let's face it, it's not that logical to have a > *mysqli* class and objects of type *mysqli.* It would make more sense to > have *mysql, mysqli, mssql, oracle *(not *oci8*), *sqlite* etc. namespaces > from a logical (and realistic) point of view. What I want to emphasize is: > Let's not use classes and repetitive prefixes for grouping purposes, > especially when we have a dedicated language feature for that. -1 > 2. TYPE HINTING. Currently PHP supports argument type hinting for arrays and > objects. As I know, it's also been decided to offer support for this in > function return values. For me it is hard to understand why not offer > support for type hinting of scalar values as well. Hinting *string*, *int*, > *float* and *bool* values can save a lot of debugging time and would provide > a great mechanism for early detection of bugs. It will also allow developers > to avoid writing hundreds of lines of code (with *is_type *tests) in a > medium application just to ensure their parameters are of the expected type. > It's better and faster to have checks at compile time. This has been discussed many times. The problem seems to be if something of a different type is passed, do you try to type juggle or throw an error; also if type juggle - should the rules be stricter than normal ? I agree that this would be a good idea - and could lead to better/faster code. +1 -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include 1. SYSTEM NAMESPACES. There are many PHP built-in functions that act on > certain groups of entities. The best examples are the *array_** and > *str* *functions. > There are many of them, and it gets really cumbersome to repeat the same > prefix for each and every one. This is clearly a reminiscence of original Come on. Is it really that hard to write strlen? Or array_merge? Would it be better if they were len (of what?) and merge (what?)? I don't think so. > procedural-style PHP. But now we have namespaces, that were introduced > exactly for this kind of situations. Why not take advantage of it? PHP can Nope. The namespaces were introduced to manage deep and wide class hierarchies, especially large frameworks with hundreds of classes, not to bother little string functions that never hurt anyone. > 2. TYPE HINTING. Currently PHP supports argument type hinting for arrays and > objects. As I know, it's also been decided to offer support for this in > function return values. For me it is hard to understand why not offer Decided by whom? When? > support for type hinting of scalar values as well. Hinting *string*, *int*, > *float* and *bool* values can save a lot of debugging time and would provide This topic was discussed to death on the list, please read the archives. If after that you still do not understand what it is about, or have some comments, please ask then. > code coincides with the global namespace ( \ ) code, I think it's safe to > remove the *define* function and possibly allow the *const *keyword to > define runtime constants as well (when the value is not a constant > expression). That would not work since code can not be run when class is being parsed, and after that it is not clear when it is supposed to be run and in what context, etc. But more importantly - what for? If you need to calculate something, make it a variable and calculate it in the ctor. Constants aren't meant to be results of complex calculations, they are meant to be simple and fixed. There was a proposal for read-only variables and one for per-variable getters/setters (actually, with some effort you can do it right now, a bit less efficiently maybe but doable). This might be direction to go in this case. > 4. PARAMETER ORDER. As noted in an older PHP meeting: Two letters: BC. Changing variable order in an existing function is a big fat BC break. And if we put such a bomb into a new version, what would be the incentive for people to use it? So that apps would have to be shipped in 2 versions, for the old php and the new php? > These were the major issues that came to my mind until now. I am sure many > things and ideas can be rejected with the reason of backward compatibility > and fear of breaking tons of lines of ancient code. But existing code can Please remember - what you call "ancient code" other people call "application on which my paycheck depends". So I think we should be super-extra-careful when messing with it. That doesn't mean we would never do any BC-breaking change ever - that does mean there always has to be a very good reason for it. And I personally don't see "consistency" being good enough reason. Don't get me wrong - it's good, it's just not good enough to be valued over working applications. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #48029 — Mark Skilbeck — 2010-04-21T05:29:19+00:00 URL: https://externals.io/message/48023#48029 · In reply to: #48023 > Hi everyone, > > [...] > > Thank you for your time, > > Adrian Nita > The PHP-way is to NEVER BREAK BC! --- ## #48031 — Ferenc Kovacs — 2010-04-21T05:57:46+00:00 URL: https://externals.io/message/48023#48031 · In reply to: #48029 On Wed, Apr 21, 2010 at 7:29 AM, Mark Skilbeck wrote: > > > > […] > The PHP-way is to NEVER BREAK BC! > > Except when you can do some cool stuff, or you are a lazy dev, and easier to do BC, than correctly fix something, or both. Tyrael --- ## #48033 — Adi Nita — 2010-04-21T09:46:23+00:00 URL: https://externals.io/message/48023#48033 · In reply to: #48028 Hi, Come on. Is it really that hard to write strlen? Or array_merge? Would it be > better if they were len (of what?) and merge (what?)? I don't think so. I think you missed the point when I said we should use system namespaces. There are several ways in which to use namespaces, including aliasing. > > procedural-style PHP. But now we have namespaces, that were introduced > > […] > > Nope. The namespaces were introduced to manage deep and wide class > hierarchies, especially large frameworks with hundreds of classes, not to > bother little string functions that never hurt anyone. > > You know, there is a world out there too, outside the "deep and wide class hierarchies". I really doubt that namespaces were introduced in the language with the sole purpose of grouping hundreds of classes. But you can, if you make everything a class. > > > 2. TYPE HINTING. Currently PHP supports argument type hinting for arrays > > […] > > Decided by whom? When? > > Here http://www.php.net/~derick/meeting-notes.html#type-hinted-properties-and-return-values. But this may be outdated, sorry if I may not know well. > > code coincides with the global namespace ( \ ) code, I think it's safe to > > […] > > That would not work since code can not be run when class is being parsed, > and after that it is not clear when it is supposed to be run and in what > context, etc. But more importantly - what for? If you need to calculate > something, make it a variable and calculate it in the ctor. Constants aren't > meant to be results of complex calculations, they are meant to be simple and > fixed. > There was a proposal for read-only variables and one for per-variable > getters/setters (actually, with some effort you can do it right now, a bit > less efficiently maybe but doable). This might be direction to go in this > case. > > When I said global namespace, I meant outside any class as well, where we would normally use *define*. My focus was that constants are not meant to be nor simple, nor complex, but just... constant. I cannot use a variable computed in the ctor or anywhere else, because that would not be constant. Simulating readonly properties with a combination of private access and a magic getter is probably a good example of bad code. > > 4. PARAMETER ORDER. As noted in an older PHP meeting: > > […] > > Two letters: BC. > Changing variable order in an existing function is a big fat BC break. And > if we put such a bomb into a new version, what would be the incentive for > people to use it? So that apps would have to be shipped in 2 versions, for > the old php and the new php? > > What you call a bomb, I call a fix in the language. People should use it because it is better, not because it is "more". Current apps are shipped in two versions, for both PHP 4 and 5? No. Take a look at Python 3 for another example. In the long run, it's more acceptable to break some code once with a new feature (and devs will know why and what to fix), than have the code break itself over the time due to bad design. > > Please remember - what you call "ancient code" other people call > "application on which my paycheck depends". So I think we should be > super-extra-careful when messing with it. That doesn't mean we would never > do any BC-breaking change ever - that does mean there always has to be a > very good reason for it. And I personally don't see "consistency" being good > enough reason. Don't get me wrong - it's good, it's just not good enough to > be valued over working applications. > I totally agree with the phrase "application on which my paycheck depends". But applications are developed, fixed and maintained, they are not static, nor statues that we stare at. I cannot agree with the idea of preferring working applications to good working applications. Our main focus here is the language and developers' main focus is their applications. So, indeed, my opinion is that PHP should take several design decisions in the future even though some are bolder than others, because I believe applications will benefit from this in the long term. I don't refer to the proposals above, but to any solid change that deserves a chance. With breaking code in mind, we'll have only things added up and end up with a much bigger and only slightly better PHP. --- ## #48034 — Peter Lind — 2010-04-21T09:57:22+00:00 URL: https://externals.io/message/48023#48034 · In reply to: #48033 > I cannot agree with the idea of preferring > working applications to good working applications. Except that's not what's at stake. The application does not become one bit better or worse by using an updated function that's more consistent with other functions. The *language* is what might become better or worse by the change, not any applications. The *side-effect* however, is that you're forcing incredible amounts of developers to fix code if they want to move it to a newer version of PHP. With the risk of having tons of code break or just never migrated to newer versions of PHP with all the problems which that creates. A better option would probably be to introduce functions that essentially do exactly the same as the old ones but consistently with the other functions. Then deprecate the old functions slowly - no instant BC break and people can migrate to the new proper functions in good time. Regards Peter -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 > […] > Come on. Is it really that hard to write strlen? Or array_merge? Would > it be better if they were len (of what?) and merge (what?)? I don't > think so. No, it is not hard to write strlen but I would also like to see these functions organized better. I've felt that PHP has been a mess since I learned it way back when, the naming inconsistencies are everywhere. > > […] > This topic was discussed to death on the list, please read the archives. > If after that you still do not understand what it is about, or have some > comments, please ask then. Sure, it has been discussed over and over but the fact that it keeps coming up here should show you that PHP developers want this feature. > > […] > Two letters: BC. > Changing variable order in an existing function is a big fat BC break. > And if we put such a bomb into a new version, what would be the > incentive for people to use it? So that apps would have to be shipped in > 2 versions, for the old php and the new php? Is this something that could be fixed if it's moved to a namespace? The new "alias" can have the "correct" order but original function can have the old order. > > […] > Please remember - what you call "ancient code" other people call > "application on which my paycheck depends". So I think we should be > super-extra-careful when messing with it. That doesn't mean we would > never do any BC-breaking change ever - that does mean there always has > to be a very good reason for it. And I personally don't see > "consistency" being good enough reason. Don't get me wrong - it's good, > it's just not good enough to be valued over working applications. I agree here but again, it could probably be worked around with some thought. These are a few items that I'd like to see worked on, as a PHP developer anyway. At the same time, I'd like to thank the internal developers. Several other things that were on my list have been worked on, specifically Late Static Bindings. Thanks again, these are just my comments, not meant to offend anyone. --- ## #48037 — Lukas Kahwe Smith — 2010-04-21T13:30:06+00:00 URL: https://externals.io/message/48023#48037 · In reply to: #48036 > > […] > > Sure, it has been discussed over and over but the fact that it keeps coming up here should show you that PHP developers want this feature. check out the RFC's on the topic. See if you want to champion one of them, or add another one if you have different ideas. > > […] > > Is this something that could be fixed if it's moved to a namespace? The new "alias" can have the "correct" order but original function can have the old order. Right, if we ever namespace internal stuff (obviously there would be a need for some out of the box BC extension), than this would be the moment to fix stuff like this. Anyways, if anyone cares about any of the above proposals write up an RFC (or champion an existing one). Lets not end up in a situation where we have to refer people to the archives to understand a previous decision ever again. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #48038 — Derick Rethans — 2010-04-21T13:30:41+00:00 URL: https://externals.io/message/48023#48038 · In reply to: #48036 > > […] > > Is this something that could be fixed if it's moved to a namespace? The new > "alias" can have the "correct" order but original function can have the old > order. No, it would me having two implementations. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #48039 — Stan Vassilev — 2010-04-21T14:03:15+00:00 URL: https://externals.io/message/48023#48039 · In reply to: #48028 > Come on. Is it really that hard to write strlen? Or array_merge? Would it > be better if they were len (of what?) and merge (what?)? I don't think so. > Ahem. We all secretly know how it should've been from the very start. Pseudo-methods for the basic types. $array->merge($array2); $string->len(); Regards, Stan Vassilev --- ## #48040 — Sean Coates — 2010-04-21T14:05:24+00:00 URL: https://externals.io/message/48023#48040 · In reply to: #48036 > No, it is not hard to write strlen but I would also like to see these functions organized better. I've felt that PHP has been a mess since I learned it way back when, the naming inconsistencies are everywhere. I don't believe there's anything stopping you (or other users) from creating either userspace or extension wrappers to handle organization and consistency. You could even use the "system" namespaces, since they don't exist. S --- ## #48041 — Stan Vassilev — 2010-04-21T14:06:55+00:00 URL: https://externals.io/message/48023#48041 · In reply to: #48038 > > […] > > No, it would me having two implementations. > > Derick There's only one way to both maintain BC during a "transition" period, and fix flaws to prepare for the next 10 years. And that's having two implementations. The original one will gradually be deprecated and eventually removed. Regards, Stan Vassilev --- ## #48042 — Jacob Oettinger — 2010-04-21T14:18:47+00:00 URL: https://externals.io/message/48023#48042 · In reply to: #48039 > > Ahem. We all secretly know how it should've been from the very start. Pseudo-methods for the basic types. > > $array->merge($array2); > $string->len(); > Yes. Maybe implemented so that they can be called like functions in a namespace for each type with the "this" value as the first param. So that: $array->merge($array2); <=> \array\merge($array, $array2); and \string\len($string); <=> $string->len(); Regards, Jacob --- ## #48043 — Alain Williams — 2010-04-21T14:28:26+00:00 URL: https://externals.io/message/48023#48043 · In reply to: #48042 > > > > […] > > Yes. Maybe implemented so that they can be called like functions in a namespace for each type with the "this" value as the first param. So that: > > $array->merge($array2); > <=> > \array\merge($array, $array2); > > and > > \string\len($string); > <=> > $string->len(); We then run into a danger of conflict with a user defined namespace \array. Could I suggest the _ prefix trick, so that the above, if we do it, becomes: \_array\merge($array, $array2); \_string\len($string); Ie all 'internal' ones start '_', such names *should* not be used by programmers. 'should', I did not write 'may'. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include I don't believe there's anything stopping you (or other users) from creating either userspace or extension wrappers to handle organization and consistency. You could even use the "system" namespaces, since they don't exist. True, the thought has crossed my mind. But I'm more concerned about performance than organization. I don't know how to make a C extension, but rather would have to make a PHP namespace. Derick Rethans wrote: > No, it would me having two implementations. Although I don't know C, couldn't you do something like: namespace Foo; funciton bar($arg1, $arg2) { return foo_bar($arg2, $arg1); } Stan Vassilev wrote: > Ahem. We all secretly know how it should've been from the very start. > Pseudo-methods for the basic types. > > $array->merge($array2); > $string->len(); I like this. Although wouldn't this be more of a strict data type way of doing things? Lukas Kahwe Smith wrote: > Right, if we ever namespace internal stuff (obviously there would be a > need for some out of the box BC extension), than this would be the > moment to fix stuff like this. > > Anyways, if anyone cares about any of the above proposals write up an > RFC (or champion an existing one). Lets not end up in a situation > where we have to refer people to the archives to understand a previous > decision ever again. I'm sure it would be a huge undertaking, I'm just saying that it would be nice to see. If I knew C I would try to help out, unfortunately I don't yet. That is why these are all just my comments. I can't act on them but want to voice my opinion. Again, it's up to all the great developers here. There are a couple good proposals out there, either would fit. But, is there something like type check foo(string $message) vs casting foo((string) $message)? Thanks, Ryan --- ## #48045 — Adi Nita — 2010-04-21T16:13:45+00:00 URL: https://externals.io/message/48023#48045 · In reply to: #48043 Hi, There is already a convention that reserved (magic) function names start with __ (double underscore). This may be extended to reserved namespaces, as I pointed out in the original message. Then, one can use say *__array* as it is, or can alias it with a shorthand notation. Maybe we can turn to have a look at *using namespace std* in C++ as a usage example. On Wed, Apr 21, 2010 at 5:35 PM, Hartmut Holzgraefe < hartmut.holzgraefe@gmail.com> wrote: > which leads to the main problem i have with readingOO code > (no matter what language actually): > > with array_merge($array1, $array2); > i can search for array_merge in the code and in the documentation > easily ( e.g. check http://php.net/array-merge ) > I was not implying to turn basic (scalar or compound) data types to classes, because that would be a too dramatic change and I don't want PHP turned into Ruby or Java :-) However, namespaces are suited when organizing code into libraries and you don't need the overhead and complexity of OO. We'd underestimate namespaces if we used them only for grouping "hundreds of classes and deep hierarchies". And it's not just about being hard to write * strlen*, it's about having a clear design and grouping together logical functionality. As for the http://php.net/array-merge it can be easily changed to * http://php.net/array/merge* or *http://php.net/__array/merge* or whatever :-) Same goes for searching in the code, though these seem minor reasons for a design decision. On Wed, Apr 21, 2010 at 5:06 PM, Stan Vassilev wrote: > There's only one way to both maintain BC during a "transition" period, and > fix flaws to prepare for the next 10 years. And that's having two > implementations. > > The original one will gradually be deprecated and eventually removed. > I agree. Functions that are currently grouped by some prefix in their names can be safely and gradually deprecated. Regards, Adrian > > > […] > Pseudo-methods for the basic types. > > […] > namespace for each type with the "this" value as the first param. So that: > > […] > > We then run into a danger of conflict with a user defined namespace \array. > Could I suggest the _ prefix trick, so that the above, if we do it, > becomes: > > \_array\merge($array, $array2); > \_string\len($string); > > Ie all 'internal' ones start '_', such names *should* not be used by > programmers. > 'should', I did not write 'may'. > > -- > Alain Williams > Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT > Lecturer. > +44 (0) 787 668 0256 http://www.phcomp.co.uk/ > Parliament Hill Computers Ltd. Registration Information: > http://www.phcomp.co.uk/contact.php > Past chairman of UKUUG: http://www.ukuug.org/ > #include You know, there is a world out there too, outside the "deep and wide > class hierarchies". I really doubt that namespaces were introduced in > the language with the sole purpose of grouping hundreds of classes. But > you can, if you make everything a class. Of course, you know much more that I do about why namespaces were introduced, but while there is indeed wide world out there, namespaces aren't meant to be everything to everybody in this world. They were meant to solve specific problem, which is management of name hierarchies, because as they grew wider and deeper, names grew longer and more complex to avoid name collisions, and that became a serious nuisance. You can, of course, use namespaces for other things, but renaming `strlen()` doesn't seem to me being worth it. > Here > http://www.php.net/~derick/meeting-notes.html#type-hinted-properties-and-return-values. > But this may be outdated, sorry if I may not know well. Since 2005 a lot happened... return type hints still don't have consensus required to introduce them, and ample discussion can be found in the archives if you are interested in the reason why. > When I said global namespace, I meant outside any class as well, where > we would normally use /define/. My focus was that constants are not So why not use `define()`? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #48047 — Stanislav Malyshev — 2010-04-21T17:36:55+00:00 URL: https://externals.io/message/48023#48047 · In reply to: #48043 Hi! > \_array\merge($array, $array2); > \_string\len($string); how it's better or more clean than array_merge or strlen? I am a big fan of OO and use it all the time, but there's a virtue in moderation - if you just want a length of a string, you son't have to build class hierachy with design patterns on top to do it - just take the length of the string! -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #48048 — Stanislav Malyshev — 2010-04-21T18:15:29+00:00 URL: https://externals.io/message/48023#48048 Hi! > It is not. It would, however, be a way to fix stuff like argument > ordering inconsistencies without causing a BC break. Well, let the hundred flowers bloom - if somebody writes an extension that does that - provided that old ones still in place - we could see if it proves popular or not. RFC and then extension is a way to go here I think. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #48049 — Alain Williams — 2010-04-21T18:18:36+00:00 URL: https://externals.io/message/48023#48049 · In reply to: #48047 > Hi! > > > […] > > how it's better or more clean than array_merge or strlen? I am a big fan > of OO and use it all the time, but there's a virtue in moderation - if > you just want a length of a string, you son't have to build class > hierachy with design patterns on top to do it - just take the length of > the string! I agree with you. I just wanted to avoid namespace name pollution by proposing a reservation of some of the name space *IF* this idea goes ahead -- I do not think that it is a good idea - for the reasons that I gave when this was first proposed. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include