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.holzgra...@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 <sv_for...@fmethod.com>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 On Wed, Apr 21, 2010 at 5:28 PM, Alain Williams <a...@phcomp.co.uk> wrote: > On Wed, Apr 21, 2010 at 04:18:47PM +0200, Jacob Oettinger wrote: > > > > On 21/04/2010, at 16.03, 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(); > > > > > > > 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 <http://www.ukuug.org/%0A#include> <std_disclaimer.h> >
