Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40370
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain iamjochem.com from 194.109.193.121 cause and error)
Message-ID: <48C57877.6060400@iamjochem.com>
Date: Mon, 08 Sep 2008 21:09:43 +0200
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: Elizabeth M Smith <auroraeosrose@gmail.com>, internals@lists.php.net
References: <ADD0525F-F900-4F3A-9B76-1ED332CA31E0@pooteeweet.org> <486FA5FB.1000300@php.net> <E06A1FB3-971F-4D4F-850A-D0255F7275F7@pooteeweet.org> <48C55855.4080602@zend.com> <A077B6EC-3E30-4F46-91CA-FD75D578CC7A@pooteeweet.org> <48C5624A.1040901@zend.com> <F4.39.33249.21565C84@pb1.pair.com> <48C56743.2060706@zend.com> <48C56DDF.3060301@iamjochem.com> <48C57296.6020200@zend.com>
In-Reply-To: <48C57296.6020200@zend.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: towards a 5.3 release
From: jochem@iamjochem.com (Jochem Maas)

Stanislav Malyshev schreef:
> Hi!
> 
>> for the same reason you would want it with classes?? because you can
>> do it with classes, no? and that seems acceptable to you, no? then 
>> functions
>> should have the same privilege.
> 
> Functions and classes are rather different things. Class represents, as 
> you know, group of data and behavior, function is much smaller. You have 
> maybe two dozens of built-in classes in PHP that reside in global space, 
> and many of them (like SPL) can be moved out relatively easily to own 
> namespaces. You have hundreds, if not thousands, of internal functions, 
> most of them  can't be moved anywhere. So having functions imported into 
> global space is much less useful and much more dangerous than the same 
> for classes.

guns are dangerous yet they are sold by the bucket load. either don't
sell guns or let people decide how to use them, don't sell'em then dictate
that they can't pull the trigger.

> It is also much less useful from one more perspective - when you import 
> a class, you get a bunch of functions which represent functionality 
> unit. With single function you probably get only a small piece, so if 
> you use a library you probably have dozens of functions there. If you 
> think importing all of them into global space through "use" is a good 
> idea, I think you need to do some refactoring there. 

I won't be using namespaces in 'real life' code at all. I've never
encountered a symbol clash on a class, function or constant in my code
and the day I do I'll rename, search and replace to fix it ... as it
stands namespaces offer me nothing but obtuse abstraction, increased code
brittleness and general stress ... I can do without that lot, which is a
pity because conceptually namespaces are a good idea, I'd love to
be able to reduce my symbol pollution in the global scope and logically
'package' various functionality inside some a defined space.

> It would grow to be 
> unmaintainable rather fast. I'd recommend putting them into a namespace 
> (if for some reason you have classes) and then just use Utility::func() 

I'm sorry is that a function in namespace Utility or a static method of
class Utility?

> - it's really not that bad.

no it really is that bad, namespaces as they stand have merely moved the
goalposts of symbol clashing somewhat whilst at the same time making
code less understandable when reading/auditing [php] source code
(e.g. load order dictating what exactly will be instantiated, the function-or-static-method
WTF).

I understand your concerns about performance, of course namespaces need
to be performant in order to be truly usable in production BUT clear, usable
functioning needs to take priority before performance is considered ...
otherwise your putting the horse before the cart so to speak. Elizabeth and
Greg have both stipulated the issues clearly - they need to be tackled or
you will end up with something that is going to make the language less usable
and not more so.

as it stands now prefixing class names with a project specific string and
using abstract classes to fake namespacing of functions is still a more
usable way to go than implementing namespaced code. I don't supposed that's
the intention?