Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40411
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.124 cause and error)
Message-ID: <48C6912E.2040500@lsces.co.uk>
Date: Tue, 09 Sep 2008 16:07:26 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
MIME-Version: 1.0
To: Greg Beaver <greg@chiaraquartet.net>
CC: PHP internals <internals@lists.php.net>
References: <48C5F612.6090001@lsces.co.uk> <48C60671.4040608@chiaraquartet.net> <48C6120E.6020606@lsces.co.uk> <48C680B9.8020603@chiaraquartet.net>
In-Reply-To: <48C680B9.8020603@chiaraquartet.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: 5.3 Backwards Compatibility
From: lester@lsces.co.uk (Lester Caine)

Greg Beaver wrote:
> Lester Caine wrote:
>> OK usual thing :( - not my problem
>> But in order to TEST PHP5.3 one needs a complete set of packages used
>> WITH ones application - without damaging the working copies of PHP and
>> this is easier if one CAN simply create a working set of files without
>> having to monitor downloads. Some key features that were available in
>> PHP seem only to be available in PEAR now :(
> 
> Lester I mean no disrespect to you with my next rather blunt comment: I
> have absolutely no idea what key features you are talking about here.
> If it is important, and the features really are missing, you have 2
> recourses
Main problem here - I think - is that in the past I managed to work without 
PEAR, but increasingly I'm finding some PEAR package needs to be installed to 
do things which in the past simply worked :( Since the customer sites are 
secure without internet access, simply downloading things via the installer 
does not work. This may simply be because libraries that included some of this 
stuff are now simply switching to PEAR instead.

> 1) do something
I create my own local copies and install from that.
Nothing else I can do and nothing I can contribute since there is no interest 
in that approach ....
I can then freeze a copy that works with the server configuration and I'm not 
messed up as I have been in the past because something gets changed.

> 2) complain
> 
> Only 1 actually accomplishes anything.
> 
>>>> I get the distinct impression that those pushing for PHP5.3 are simply
>>>> not making a good case for many of us to even want to follow them down
>>>> that path? It almost feels like this is a DIFFERENT path to the main
>>>> stream of PHP6 which many of us are much more desperate to be testing in
>>>> the field, which seems to have become an ignored backwater? Key elements
>>>> which have been flagged to PHP6 ( such as BIGINT ) are on hold while new
>>>> concepts which were not part of the PHP6 reoadmap have been forced
>>>> through? Since current hardware *IS* 64 bit, actually handling 64 bit
>>>> numbers properly would be nice :)
>>> I think I have made an excellent case for the things that I care about
>>> in 5.3.
>> Making a case that you like something and convincing people that there
>> is some point in our using it a different matter. I can see the reason
>> for namespace, but I have yet to be convinced that the current
>> implementation is not just a bodge job since there seems to be so many
>> holes in it still :(
> 
> I was referring to ext/phar, but there is no way you could have known
> that from my snide comment.  I was also referring to the multiple tweaks
> to namespaces, as it is my personal quest to make them a little more
> user-friendly (from my perspective) than they are right now.  I happen
> to believe that a good feature doesn't *need* much advocacy beyond
> documentation for people to use it, and both ext/phar and namespaces do
> have documentation.  Of course, any problems found in the docs during
> this alpha phase should immediately be reported at bugs.php.net where
> they will be fixed (read: not here, where they create noise), including
> abstract structural issues with the organization or confusing language.

phar is something else I do not so any advantage to using. So as long as it's 
not 'turned on by default' like a few other other sections of PHP5.3 have been 
then no problem, but packaging 100Mb of bitweaver in a single code file just 
seems wrong to me? And the biggest pain with Java JAR's is having to rebuild 
everything every time you want to make a simple change. OK they may make sense 
for libraries, but again we have to re-package every time we want to tweak 
things. I came to PHP BECAUSE I wanted to get away from compiled and processed 
code and the ability to drop new sections in on the fly is one of it's main 
advantages.

>> I thought PHP5 OO was about creating and using classes to ring fence
>> stuff so why do we now need to ring fence the ring fence? But of cause
>> the main problem is that the major part of the PHP code base has to to
>> be converted TO OO? So most stuff we are working with is simply not PHP5
>> friendly yet?
> 
> I can't answer to this point, as my assumption about PHP5 OO was that it
> is about fixing some of the gotchas in PHP4 OO, not about shoehorning
> everything in PHP to fit into the OO box.

Most of the code that I am working on is a miss-mash of PHP4 code with classes 
added and other 'packages' of code. Steph - the code does not need converting 
to OO, but it does make sense to continue that progress on areas that have yet 
to be converted. I'm just seeing 'namespaces' as a means of wrapping non-OO 
code rather than tidying it up into classes, and the current comments seem to 
imply that they are not really set up even to do that yet?

-- 
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