Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41066
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: Lester Caine <lester@lsces.co.uk>,
 internals@lists.php.net
Message-ID: <7C5A9831-9703-4DB5-B66C-83B61C3B7D7F@pooteeweet.org>
To: Ron Rademaker <ron@connectholland.nl>
In-Reply-To: <48F5B963.8000301@connectholland.nl>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 15 Oct 2008 11:35:43 +0200
References: <3CF765DF-27AF-44FD-9ECF-BEBFC8A0AFCA@pooteeweet.org> <alpine.DEB.0.98.0810150853100.30375@kossu.ez.no> <48F5A349.4000909@lsces.co.uk> <48F5A4D6.2080904@connectholland.nl> <48F5B4D9.3030109@lsces.co.uk> <48F5B963.8000301@connectholland.nl>
Subject: Re: [PHP-DEV] namespaces and alpha3
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 15.10.2008, at 11:35, Ron Rademaker wrote:

> Lester Caine wrote:
>>>
>>> What would be the advantage of wrapping legacy functions in a  
>>> namespace over wrapping them into a class as static functions?
>>
>> THAT is probably why I am asking the question? And may well be key  
>> to my understanding why converting non OO code into OO code in PHP  
>> is so problematic. When I was coding in CC++ more heavily libraries  
>> did not need to be objects and the 'namespace' just wrapped the  
>> code OR the code was built as an object. That is what I understand  
>> by a namespace, so perhaps I do not understand why leaving out  
>> functions and constants is acceptable :(
>
> I don't think there's any difference between moving non OO functions  
> to a class and making the static and moving those to a namespace (in  
> a suggested syntax it would be: Bar:::foo() for a namespace and  
> Bar::foo() already for a class). Even more, I think there are  
> advantages for moving a legacy app to a class because it allows you  
> to make your global variables (like things in legacy apps) class  
> members. Of course that's only an advantage if you agree that  
> globals are evil...
>
> So my conclusion would be that leaving out functions and constants  
> is acceptable because there's no advantage of having those in a  
> namespace. Classes already provide everything you would possibly  
> want from namespaces for functions and constants.


well you cannot split a class definition across several files. so if  
you move your functions to a class, you need to move them all to a  
single file.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org