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
