Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48024
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain phcomp.co.uk designates 78.32.209.33 as permitted sender)
Date: Tue, 20 Apr 2010 15:52:04 +0100
To: Adi Nita <adi.nita@gmail.com>
Cc: internals@lists.php.net
Message-ID: <20100420145203.GT4541@phcomp.co.uk>
Mail-Followup-To: Adi Nita <adi.nita@gmail.com>, internals@lists.php.net
References: <t2y294a23a11004200739v6b3e18f1z52abfa89db643a09@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <t2y294a23a11004200739v6b3e18f1z52abfa89db643a09@mail.gmail.com>
User-Agent: Mutt/1.4.2.2i
Organization: Parliament Hill Computers Ltd
Subject: Re: [PHP-DEV] A critique of PHP 6
From: addw@phcomp.co.uk (Alain Williams)

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>