Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41068
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.125 cause and error)
Message-ID: <48F5C272.4060900@lsces.co.uk>
Date: Wed, 15 Oct 2008 11:14:10 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
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> <7C5A9831-9703-4DB5-B66C-83B61C3B7D7F@pooteeweet.org>
In-Reply-To: <7C5A9831-9703-4DB5-B66C-83B61C3B7D7F@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] namespaces and alpha3
From: lester@lsces.co.uk (Lester Caine)

Lukas Kahwe Smith wrote:
> 
> 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.

I think this is where I'm having trouble!
'bitweaver' has a lot of sections that are in different files, and the correct 
file is selected for the configuration that you want. Functions override one 
another and the correct version of a function is used depending on various 
factors. Packages within the framework would be ideal candidates for namespace 
wrappers, but I don't thing the current structure would work?
ADOdb and Smarty are layered code and I think they have functions at the 
global level but I may be wrong there? If they do then what would be an ideal 
candidate for a namespace may not be addressed currently?

I'm currently converting legacy Builder6 applications into packages for 
bitweaver, so anything to simplify modularization would be helpful which is 
why I'm not opposed to namespace - as long as it actually works for me.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php