On Tue, Apr 20, 2010 at 05:39:07PM +0300, Adi Nita wrote: > 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 <std_disclaimer.h> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
