While I have loaded 5.3.? changing any of my existing code base to remove
warnings is not likely to happen any time soon since compatibility with users
who are still running older versions of PHP still needs to be maintained.
I've got http://wiki.php.net/doc/scratchpad/upgrade/53 which seems to be
currently the only reference to changes? But where do I find the detail on how
things ARE currently implemented such as namespace and (fingers down throat)
goto?
Another major concern here since maintaining BC with PHP4 is still an
unfortunate current requirement in the field is what happens when PEAR
actually uses namespace and other 5.3 only features. HOW will we manage
accessing versions of PEAR that are compatible with our active codebase and so
ensure that we have compatible sets of packages?
Personally I can't stand the CURRENT problems that is caused by not knowing
which version of a PEAR extension users actually have and in order to ensure a
COMPATIBLE version, but in future will the PEAR installer pick up a correct
version for the copy of PHP actually being run?
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 :)
--
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
Hi Lester,
Lester Caine wrote:
While I have loaded 5.3.? changing any of my existing code base to
remove warnings is not likely to happen any time soon since
compatibility with users who are still running older versions of PHP
still needs to be maintained.I've got http://wiki.php.net/doc/scratchpad/upgrade/53 which seems to be
currently the only reference to changes? But where do I find the detail
on how things ARE currently implemented such as namespace and (fingers
down throat) goto?
the manual is ridiculously up to date, and is the best reference
location for new features. Occasionally things are documented within
seconds of commit and in one case prior to commit. It's frightening
what they do :).
Another major concern here since maintaining BC with PHP4 is still an
unfortunate current requirement in the field is what happens when PEAR
actually uses namespace and other 5.3 only features. HOW will we manage
accessing versions of PEAR that are compatible with our active codebase
and so ensure that we have compatible sets of packages?
This and the following paragraph are questions for PEAR, and don't
concern internals developers, pear-dev@lists.php.net is the best list
for tech questions like the ones you raise. However, I will say that
PEAR has been doing just fine with the handling of PHP version
differences to date. The installer is fully aware of PHP version
dependency, and refuses to install packages that are incompatible with
your PHP version. If you find an older package that has an
incompatibility with a newer PHP version, this is considered a bug in
the package that must be fixed (again, a PEAR problem, not a PHP problem).
However, if you upgrade PHP, it is best to upgrade the existing packages
to be sure you have ones compatible with the current PHP release. This
is a tricky problem, but fortunately the most-used PEAR packages are
carefully tracked against PHP releases by their maintainers, so we have
not had a PHP version-related problem since the move to 5.0.
Personally I can't stand the CURRENT problems that is caused by not
knowing which version of a PEAR extension users actually have and in
order to ensure a COMPATIBLE version, but in future will the PEAR
installer pick up a correct version for the copy of PHP actually being run?
"pear list" show the version information you need, and PEAR since
version 1.6.0 takes into account PHP version prior to download (1.6.0
was released June 7, 2007)
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.
;)
Greg
Greg Beaver wrote:
Hi Lester,
Lester Caine wrote:
While I have loaded 5.3.? changing any of my existing code base to
remove warnings is not likely to happen any time soon since
compatibility with users who are still running older versions of PHP
still needs to be maintained.I've got http://wiki.php.net/doc/scratchpad/upgrade/53 which seems to be
currently the only reference to changes? But where do I find the detail
on how things ARE currently implemented such as namespace and (fingers
down throat) goto?the manual is ridiculously up to date, and is the best reference
location for new features. Occasionally things are documented within
seconds of commit and in one case prior to commit. It's frightening
what they do :).
Trying to follow on from 'scratchpad' using php.net search
namespace - not found - AH - namespaces ...
goto not found
Closure - not found
Don't have time to spend hours finding the information. It takes long enough
to create a safe environment to copy things to.
<snip> 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 :(Another major concern here since maintaining BC with PHP4 is still an
unfortunate current requirement in the field is what happens when PEAR
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 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?
--
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
Hi Lester
2008/9/9 Lester Caine lester@lsces.co.uk
Greg Beaver wrote:
Hi Lester,
Lester Caine wrote:
While I have loaded 5.3.? changing any of my existing code base to
remove warnings is not likely to happen any time soon since
compatibility with users who are still running older versions of PHP
still needs to be maintained.I've got http://wiki.php.net/doc/scratchpad/upgrade/53 which seems to be
currently the only reference to changes? But where do I find the detail
on how things ARE currently implemented such as namespace and (fingers
down throat) goto?the manual is ridiculously up to date, and is the best reference
location for new features. Occasionally things are documented within
seconds of commit and in one case prior to commit. It's frightening
what they do :).Trying to follow on from 'scratchpad' using php.net search
namespace - not found - AH - namespaces ...
I guess an alias could be made for that if its that big a need :)
goto not found
Closure - not found
These things are currently on the documentation team's todo after the alpha
releases
as far as Im aware of.
Don't have time to spend hours finding the information. It takes long
enough to create a safe environment to copy things to.Another major concern here since maintaining BC with PHP4 is still an
<snip>unfortunate current requirement in the field is what happens when PEAR
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 :(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 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?--
Lester Caine - G8HFLContact - 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--
--
Kalle Sommer Nielsen
Trying to follow on from 'scratchpad' using php.net search
namespace - not found - AH - namespaces ...
Fixed, but why don't you try to raise this issue on remotely closer
mailinglist or bug report?
goto not found
Help appreciated.
Closure - not found
"The RFC can serve as documentation until someone can document it" is
the new cool today.
Don't have time to spend hours finding the information. It takes long enough
Happ shittens.
Any and all help is very appreciated.
-Hannes
Hannes Magnusson wrote:
Trying to follow on from 'scratchpad' using php.net search
namespace - not found - AH - namespaces ...Fixed, but why don't you try to raise this issue on remotely closer
mailinglist or bug report?goto not found
Help appreciated.
'Over my dead body' comes to mind ;)
The NOTES (2005?) I have relating to this do cover the intended plan, but in
order to document it one needs to know how it was actually implemented? It's
not something I would consider using, but as soon as it appears in libraries
one has to understand how it works if one gets dragged in by faults. However
if the original plan have been followed, then it's not actually goto is it?
Closure - not found
"The RFC can serve as documentation until someone can document it" is
the new cool today.Don't have time to spend hours finding the information. It takes long enough
Happ shittens.
Any and all help is very appreciated.
Greg's blanket - It's in the manual was simply wrong?
TESTING new features requires that we know that they are there and how they
work? But raising a lot more bugs for things that ARE still being padded out
is not the right way of getting the information so we can test? The current
problem is that a lot of the material has NOT been pushed back to php.net yet
- it still says that is to be done ... so one has to find these extra bits.
5.3.0 has not been released yet, and where data IS in the manual it's marked
as 'experimental' ( namespaces ... ) so what is a more appropriate list for
matters relating to getting 5.3.0 out of the door in a format that we can
actually use?
I'm trying to keep a copy of 5.3 running along side my production 5.2 machines
in order to test things out, and I have a list of things which need 'fixing'
in the applications I am using IF I'm to use 5.3 in production, but that
can't happen until it leaves 'internals' and becomes a version actually
supported on the other lists? For the moment I keep watching here and checking
for updates to the information.
--
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
But of cause the main problem
is that the major part of the PHP code base has to to be converted TO OO?
Why?
- Steph
hi Lester,
Don't have time to spend hours finding the information. It takes long enough
to create a safe environment to copy things to.
Talking about not having the time, I suppose you did not have the time
either to deal with firebird as discussed a while back? Nothing
changed so far and nothing is going to change anytime soon if nobody
steps in.
Cheers,
Pierre
Pierre Joye wrote:
hi Lester,
Don't have time to spend hours finding the information. It takes long enough
to create a safe environment to copy things to.Talking about not having the time, I suppose you did not have the time
either to deal with firebird as discussed a while back? Nothing
changed so far and nothing is going to change anytime soon if nobody
steps in.
I test everything when I can as it is updated, but as yet I have had no need
to change anything. I STILL have not got to a state where I can do much on the
windows side, and have no intention on using M$ compilers on the development
machines, but I DO now have the php_interbase code into PHPEclipse on Linux
and can at least play with it. I've just done two big upgrades which use
Apache2/FB2/PHP5.2.6 at this stage and that is unlikely to be moved to PHP5.3
as we will leave things alone now that it is running. They are on private
networks so the PEAR bits has had to be 'imported', and the IT departments
like to block my ability to change things once the systems are live.
It's native Unicode and Firebird that we need to work on hence the wish to
start playing with at least an alpha of PHP6 rather than spending time
re-testing things in PHP5.X :(
php_interbase passes all my tests fine now so what still needs doing?
( And I think my posts to internals@ are now being blocked ? )
--
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
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
- do something
- 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.
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.
Thanks,
Greg
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.
- 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.
- 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
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.
can you provide some example?
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Alexey Zakhlestin wrote:
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.can you provide some example?
For example - a bad one since these are pulled in by the project, but it is
what I have currently documented.
The crib sheet
http://www.bitweaver.org/wiki/Version2.1+Windows+niggles
was needed to help get new users working, where previous installs simply
worked from the zip.
http://www.bitweaver.org/downloads/file/11619?highlight=PEAR works with
PHP5.2.6 but gives errors on 5.3.0 Those errors now need to be isolated
between the core code and the PEAR and other libraries.
It takes some time to test every possible path in a full bitweaver install :(
--
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
Hi,
So let me get this straight, you are complaining that all the new
features and changes in the 5.3.0 alpha releases are not perfectly
documented yet?
If that is the case I really wonder how you managed to survive the
releases before?
Let me just give you a break down of how much better the situation for
5.3.0 is compared to 5.2.0 due to the combined efforts of various
teams inside PHP.net:
- there is a scratchpad that at least lists relevant changes
- most of the big new features (and some of the small) have RFC's
detailing the implementation, the concepts and some examples - several features have already been documented (although I guess
this was also the case with previous PHP releases, so this does not
really count as an improvement .. but like in previous releases as
features are tweaked the documentation can get out of sync) - we have planned to work on the upgrading guide starting with the
beta phase, previously this happened in the RC phase IIRC - from my perception new features tend to come in with more test
cases than in the past (though i might be mistaken here, but our test
coverage is improving even as we add new features) - todo list with links to relevant threads, sites, RFC etc (in the
past there were much fewer links next to todo items) - with alpha2 we even had windows releases at the same time as *nix
So yes, this means that for alpha releases, we are not spoon feeding
testers. This we are aware of and given the current ressources I think
we are in very good shape in 5.3.0 (see above for details). We
expect testers to be able and willing to figure things out by reading
RFCs, reading test cases, following links on the todo list, checking
the scratchpad, checking the documentation, being able to deal with
slightly outdated information etc.
For the beta phase we want to be able to provide a alpha quality
(meaning most things should be mentioned, but some things might not be
complete) upgrading guide. So starting with the beta releases, the
expectations we have in the testers are lowered significantly.
One we are in RC phase, the upgrading guide should be in beta state
and I expect the documentation to pick up outdated information and
fill in blanks. Though I am not involved enough in the doc team to
really tell how they operate and how quickly they can fill in the
blanks with the ressources they have.
So all in all, it seems to me like you are suffering from unreasonable
expectations. Instead you should be congratulating the entire PHP.net
crew for their gigantic leap forward.
regards,
Lukas
PS: As for PEAR I agree with Greg. Its not a topic for this list, but
suffice it to say that dependency handling is probably one of the
strongest points of PEAR.
Lukas Kahwe Smith wrote:
Hi,
So let me get this straight, you are complaining that all the new
features and changes in the 5.3.0 alpha releases are not perfectly
documented yet?
PLEASE re-read the original post.
If my comments and QUESTIONS are taken as complaints then OK. That is not what
was intended.
searching on 'namespace' was not giving me anything - I did not think to try
'namespaces' - goto has not got any notes yet? - I've not even looked at phar
as it's not on the list I gave the link for so I assume it's still an optional
PECL package ...
The 'complaint' that I have is that the changes being introduced DO seem to be
bringing in problems which when corrected for 5.3 then cause other problems
for previous versions of PHP. As an example, the bitweaver framework currently
runs out of the box on PHP4 and PHP5. RUNNING it on PHP5.3 gives various
warnings and errors that handling for 5.3 then messes up previous versions
although WHEN migration is documented there may be options provided that solve
those problems?
( And PEAR comes into this equation since potentially we may have to take care
of pre and post 5.3 situations? )
Hanging fixes through the code with 'version selects' has not been necessary
much up to now but 5.3 seems to be heading that way? We are currently working
through the bitweaver 2.1 testing, on 5.2.6 and below so have not yet had time
to do any more than checking the code runs on 5.3. The list of things to be
looked at on 5.3 was growing so has had to be shelved until the next bitweaver
release is out. One has to allocate time productively and BW is currently
paying the mortgage 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
Lukas Kahwe Smith wrote:
Hi,
So let me get this straight, you are complaining that all the new
features and changes in the 5.3.0 alpha releases are not perfectly
documented yet?PLEASE re-read the original post.
If my comments and QUESTIONS are taken as complaints then OK. That
is not what was intended.
I am pretty sure I read that you complained that information is
scattered or unavailable. If I misunderstood you I am sorry.
The 'complaint' that I have is that the changes being introduced DO
seem to be bringing in problems which when corrected for 5.3 then
cause other problems for previous versions of PHP. As an example,
the bitweaver framework currently runs out of the box on PHP4 and
PHP5. RUNNING it on PHP5.3 gives various warnings and errors that
handling for 5.3 then messes up previous versions although WHEN
migration is documented there may be options provided that solve
those problems?
( And PEAR comes into this equation since potentially we may have to
take care of pre and post 5.3 situations? )
Hanging fixes through the code with 'version selects' has not been
necessary much up to now but 5.3 seems to be heading that way? We
are currently working through the bitweaver 2.1 testing, on 5.2.6
and below so have not yet had time to do any more than checking the
code runs on 5.3. The list of things to be looked at on 5.3 was
growing so has had to be shelved until the next bitweaver release is
out. One has to allocate time productively and BW is currently
paying the mortgage for me!
Obviously the goal is to minimize BC issues as much as possible.
Actually there has to be really sound reason to break BC. So whenever
you discover a BC issue that is not noted on the scratchpad please
make us aware of this by opening a bug report or by sending a mail to
this list.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
2008/9/10 Lester Caine lester@lsces.co.uk:
Lukas Kahwe Smith wrote:
Hi,
So let me get this straight, you are complaining that all the new features
and changes in the 5.3.0 alpha releases are not perfectly documented yet?PLEASE re-read the original post.
If my comments and QUESTIONS are taken as complaints then OK. That is not
what was intended.
searching on 'namespace' was not giving me anything - I did not think to try
'namespaces' - goto has not got any notes yet? - I've not even looked at
phar as it's not on the list I gave the link for so I assume it's still an
optional PECL package ...The 'complaint' that I have is that the changes being introduced DO seem to
be bringing in problems which when corrected for 5.3 then cause other
problems for previous versions of PHP. As an example, the bitweaver
framework currently runs out of the box on PHP4 and PHP5. RUNNING it on
PHP5.3 gives various warnings and errors that handling for 5.3 then messes
up previous versions although WHEN migration is documented there may be
options provided that solve those problems?
( And PEAR comes into this equation since potentially we may have to take
care of pre and post 5.3 situations? )
Hanging fixes through the code with 'version selects' has not been necessary
much up to now but 5.3 seems to be heading that way? We are currently
working through the bitweaver 2.1 testing, on 5.2.6 and below so have not
yet had time to do any more than checking the code runs on 5.3. The list of
things to be looked at on 5.3 was growing so has had to be shelved until the
next bitweaver release is out. One has to allocate time productively and BW
is currently paying the mortgage for me!
Lester, if you have more complaints or suggestions regarding PEAR, I
would like to ask you to go on pear-dev. We'll be happy to help you
resolve the situations or work something out. Many developers there
are running 5.3 as testers and we have had all the problems.
Thank you very much,
--
Slan,
David
Hello Lester,
Tuesday, September 9, 2008, 6:05:38 AM, you wrote:
While I have loaded 5.3.? changing any of my existing code base to remove
warnings is not likely to happen any time soon since compatibility with users
who are still running older versions of PHP still needs to be maintained.
I've got http://wiki.php.net/doc/scratchpad/upgrade/53 which seems to be
currently the only reference to changes? But where do I find the detail on how
things ARE currently implemented such as namespace and (fingers down throat)
goto?
Another major concern here since maintaining BC with PHP4 is still an
unfortunate current requirement in the field is what happens when PEAR
actually uses namespace and other 5.3 only features. HOW will we manage
accessing versions of PEAR that are compatible with our active codebase and so
ensure that we have compatible sets of packages?
PHP 4 is no longer supported - in no way. If PEAR still insists on PHP 4
then we cannot support PEAR either. Anyway, as far as I know PEAR does a
good job in maintenance, especially in supporting both PHP 4 and 5. And
some people are working on a new system that supports PHP 5.
marcus
Personally I can't stand the CURRENT problems that is caused by not knowing
which version of a PEAR extension users actually have and in order to ensure a
COMPATIBLE version, but in future will the PEAR installer pick up a correct
version for the copy of PHP actually being run?
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 :)
--
Lester Caine - G8HFLContact - 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
Best regards,
Marcus
Marcus Boerger wrote:
Hello Lester,
Another major concern here since maintaining BC with PHP4 is still an
unfortunate current requirement in the field is what happens when PEAR
actually uses namespace and other 5.3 only features. HOW will we manage
accessing versions of PEAR that are compatible with our active codebase and so
ensure that we have compatible sets of packages?PHP 4 is no longer supported - in no way. If PEAR still insists on PHP 4
then we cannot support PEAR either. Anyway, as far as I know PEAR does a
good job in maintenance, especially in supporting both PHP 4 and 5. And
some people are working on a new system that supports PHP 5.
Marcus - I've never USED PHP4 in production, but it will be some time before
it has been replaced on a lot of ISP's so at present OUR users require
maintaining support for PHP on the only versions they have available - at
present. NOW it at least practical to freeze a version that supports PHP4 and
all the 'extras' that are compatible with that version and not allow any new
features to be included in that build. SO we do not have to test changes to
the code base for PHP5.3 against PHP4. There have always been problems with
using 'new' features but making them available to older versions, which the
compatibility libraries provide, but it is looking as if 'Built for PHP5.3'
will mean 'will not work on PHP5.2' much more so than previous 'minor version
changes'?
--
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
Hello Lester,
Wednesday, September 10, 2008, 7:43:25 PM, you wrote:
Marcus Boerger wrote:
Hello Lester,
Another major concern here since maintaining BC with PHP4 is still an
unfortunate current requirement in the field is what happens when PEAR
actually uses namespace and other 5.3 only features. HOW will we manage
accessing versions of PEAR that are compatible with our active codebase and so
ensure that we have compatible sets of packages?PHP 4 is no longer supported - in no way. If PEAR still insists on PHP 4
then we cannot support PEAR either. Anyway, as far as I know PEAR does a
good job in maintenance, especially in supporting both PHP 4 and 5. And
some people are working on a new system that supports PHP 5.
Marcus - I've never USED PHP4 in production, but it will be some time before
it has been replaced on a lot of ISP's so at present OUR users require
maintaining support for PHP on the only versions they have available - at
present. NOW it at least practical to freeze a version that supports PHP4 and
all the 'extras' that are compatible with that version and not allow any new
features to be included in that build. SO we do not have to test changes to
the code base for PHP5.3 against PHP4. There have always been problems with
using 'new' features but making them available to older versions, which the
compatibility libraries provide, but it is looking as if 'Built for PHP5.3'
will mean 'will not work on PHP5.2' much more so than previous 'minor version
changes'?
Seems like we're on the same track that PHP 4 stays as it is and code that
was designed for it can be happily maintained for it as well.
So we're at discussing changes inbetween the 5 series. Practically I do not
at all care for 5.0 or 5.1, they were experiements. However the move from
5.2 to 5.3 should be as easy as possible. If we have to many BC breaks
there then we need to list them all and discuss them one after the other.
marcus
--
Lester Caine - G8HFLContact - 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
Best regards,
Marcus