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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
