Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
I don't see the problem for a software with this minor BC breaks from 5.3 to 5.5. The biggest change ever happened with namespaces and so in in 5.3 should already be done. If you have to change some parts, this is done in a few hours/days, with search and replace and a little bit handwork. And for the good feeling after refactoring, there are UnitTests around today.
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Rasmus Lerdorf wrote: It would make everyone's life so much easier if all the Drupal 8 code that is being written and tested with 5.4 would just work 5.5 without *any* problem. Yup, so please test it against 5.5 now. Have you done so? It is rather trivial to do. Grab it from git or there is a tarball athttp://qa.php.net Perhaps when I've finished the time machine ... In reality we have to make choices where we DO spend time. There is still a mile of code out there being used live which is running perfectly on the PHP5.2 infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4 before we get around to 5.5. This is perhaps the main problem with accelerating the release timetable in that there simply is not enough time to bring everybody along? So something has to give and at the moment for me it's going to have to be 5.5 ... but by the time all the legacy stuff is up to 5.4 you will be way off in the distance :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
hi Karoly, On Tue, Feb 5, 2013 at 7:35 AM, Karoly Negyesi kar...@negyesi.net wrote: OK, let's try this again. Maybe language versioning is out. That's sad, but this thread brought to light a much more important problem I would like to try to address. I have long felt the PHP team is living in another world I do. Sometimes yes, sometimes no. Users form a pyramid. The bottom is shared hosts. Shared hosts that we need to take into consideration. So if the shared world just barely switched to 5.3 default then, alas, we can't release a version that requires PHP 5.4 because there is no shared support for it. Also, it worths mentioning that one of the more popular server OSes, Ubuntu LTS also doesn't have a PHP 5.4 yet. Without software demanding 5.4, hosts won't upgrade. This is a vicious circle that is superb hard to break. And we changed what we used to be or used to do to ease this process. I was told in this thread that the new release process solves this and it is our and our users role to explain that to their ISPs, admins, etc. Well, what am I to explain? As I mentioned previously, if a shared host does a PHP upgrade and their users see new error messages, then the host have a support problem. Explaining new notices or warnings being non fatal or not adding BC issues are what apps/libraries developers should document, for previous versions. Fixing them in newer updates (even minor) is easy and will still work when executed on older PHP versions. It would make everyone's life so much easier if all the Drupal 8 code that is being written and tested with 5.4 would just work 5.5 without *any* problem. That's why we do test almost all commits with all major apps or frameworks. And that's why you should do it as well with your apps and report any actual BC breaks. I would absolutely love not to have this conversation again three years from now when we need to decide to ship Drupal 9 with PHP 5.5 or 5.4 -- because we could indeed do a campaign when 5.4 is due to change to 5.5 outright because it won't break BC with 5.4. Is this absolutely unattainable? What seems to be unattainable to me is this kind of discussions, you kept on your positions and refused to understand the actual need of adding notices or warnings for non supported/edge cases where the code behavior cannot be guaranteed. This is a circular discussion and I don't see how it could end. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.02.2013 09:14, schrieb Lester Caine: f code out there being used live which is running perfectly on the PHP5.2 infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4 before we get around to 5.5. This is perhaps the main problem with accelerating the release timetable in that there simply is not enough time to bring everybody along? So something has to give and at the moment for me it's going to have to be 5.5 ... but by the time all the legacy stuff is up to 5.4 you will be way off in the distance :( Actually, it doesn't matter. Three years worth of changes are just the same, be it in one or three versions. With faster and less radical steps, there is a better chance the provider's upgrade cycle fits PHP's upgrade cycle and just misses by one or two minor changesets rather than one big. It also makes make the site work again a more regular, but easier task and increases customers' awareness that unmaintained web software will not continue to run indefinately. Just as putting your legacy DOS app onto a new computer after the 15 year old legacy system finally broke down will require some brains to make work again. As a supporter / hired external consultant I would like that. - -- Ralf Lang Linux Consultant / Developer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEQ6/UACgkQCs1dsHJ/X7Dp+QCg0prN0juyUojOuJRJ5GM1TwdS sr8An28l0a18Idsfh6kw/8xPZ8cQwrJH =65H6 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
- Ursprüngliche Message - Von: Lester Caine les...@lsces.co.uk An: internals@lists.php.net internals@lists.php.net CC: Gesendet: 9:14 Dienstag, 5.Februar 2013 Betreff: Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning Rasmus Lerdorf wrote: It would make everyone's life so much easier if all the Drupal 8 code that is being written and tested with 5.4 would just work 5.5 without *any* problem. Yup, so please test it against 5.5 now. Have you done so? It is rather trivial to do. Grab it from git or there is a tarball athttp://qa.php.net Perhaps when I've finished the time machine ... In reality we have to make choices where we DO spend time. There is still a mile of code out there being used live which is running perfectly on the PHP5.2 infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4 before we get around to 5.5. Why do you change the infrastructure if the code does not need it? I mean, provide the infrastructure the code needs and done. There is more than one vendor that offers support for PHP 5.2 infrastructure in the market. What's the deal? This is perhaps the main problem with accelerating the release timetable in that there simply is not enough time to bring everybody along? So something has to give and at the moment for me it's going to have to be 5.5 ... but by the time all the legacy stuff is up to 5.4 you will be way off in the distance :( There was no acceleration in the release timetable from my point of view. The whole show was stopped between PHP 5.2 and 5.3. This has been fixed now by explicitly having the one-year rhythm for major releases again - documented publicly for the first time in PHP history (IRC). I like the idea to know that a new major is scheduled for the first of march. The equinox, can't you feel it? Would be great to know we get PHP 5.6 shipped until the next solar eclipse. Also these yearly release period (the Rhythm) does not mean that it accelerated. It just helps you (and everybody else) with dancing, coordinating and planning. E.g. you can choose your speed by explicitly for example by leaving one major version out (skipping it) because you know when you can expect the next major release - thanks to rhythm - as well as you know how long it will be supported by the project. When we got rhythm I can call my jamaican guy while being a slave to it. Grace Jones knew that. It's all leisure, no stress. The PHP userbase just grew too large you can find a solution for everyone. Having a clear release rhythm still helps everyone and looks like an appropriate tool to me. And yeah, code, you need to refactor, always. We can't change that, nobody can. PHP might have made us lazy, which is fine, however, time goes by. Just some weeks ago I killed one of my PHP 5 babies (and it could have run even longer technically, despite the PHP releases since it saw light of day). The whole application is not needed any longer (thanks to the great improvements we have with frameworks and libraries since PHP 5.3 and 5.4). Don't work against the community, try to find good solutions of which everybody can benefit. Sure we all have issues, but the key point is to be flexible with the solutions. Be it just taking the releases of PHP 5.2 supported by third-party vendors or keeping up with the later stable leaving a time-window of three years to switch between one PHP version to the other. Additionally if even this time-frame does not work out for more than *one* version change, you can even skip up to two major versions to keep up with the rest of the gang to latest. I think it was never that easy as it is today. -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
hakre wrote: In reality we have to make choices where we DO spend time. There is still a mile of code out there being used live which is running perfectly on the PHP5.2 infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4 before we get around to 5.5. Why do you change the infrastructure if the code does not need it? I mean, provide the infrastructure the code needs and done. There is more than one vendor that offers support for PHP 5.2 infrastructure in the market. What's the deal? The point here is supporting customers that I've 'acquired' who are currently hosted on services that control that infrastructure. The long term aim is to move them to servers under our control, but in the meantime until contracts run out we have to live with such activity as 'We will be updating to PHP5.3 on the 1st April'. The problem now is how to deal with that situation, and paying up outstanding contracts may be the solution. The code needs updating, and updating to 5.4 would be useful, but short term everything needs testing and fixing for PHP5.3 :( The whole reason that ISP's are currently moving from PHP5.2 to PHP5.3 rather than PHP5.4 is that there is a better chance that their client sites will continue to work. http://w3techs.com/technologies/history_details/pl-php/5 use of PHP5.1 is slowing faster than 5.4 use is growing. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
This is a circular discussion and I don't see how it could end. I do. Let's put up an RFC for it. That is one of the reasons we established that process, isn't it? So that ideas like this don't just end up in infinite discussions that go nowhere? Karoly, are you familiar with our RFC process? If not, take a look at http://wiki.php.net/rfc. You've clearly invested a lot of thought into this, so let's go ahead and put that into an actual proposal. I'll be glad to help, including posting it to the wiki if you don't have an account. I'll be honest: I don't think it'll pass. I'd be voting no on it if that vote were held right now. But at least you'll have an actual proposal on record and you'll have at least a week (or is it two?) to try to change people's minds before it goes to a vote. I think that would be the best way to close the lid on this. If somebody brings it up again in the near future, we can simply point them to the RFC to demonstrate that the issue has already been raised and decided. Problem solved. If anybody has a better idea on how to put this discussion to rest, I'm all ears. =) --Kris
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
- Ursprüngliche Message - Von: Lester Caine les...@lsces.co.uk An: internals@lists.php.net internals@lists.php.net CC: Gesendet: 13:42 Dienstag, 5.Februar 2013 Betreff: Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning hakre wrote: In reality we have to make choices where we DO spend time. There is still a mile of code out there being used live which is running perfectly on the PHP5.2 infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4 before we get around to 5.5. Why do you change the infrastructure if the code does not need it? I mean, provide the infrastructure the code needs and done. There is more than one vendor that offers support for PHP 5.2 infrastructure in the market. What's the deal? The point here is supporting customers that I've 'acquired' who are currently hosted on services that control that infrastructure. The long term aim is to move them to servers under our control, but in the meantime until contracts run out we have to live with such activity as 'We will be updating to PHP5.3 on the 1st April'. The problem now is how to deal with that situation, and paying up outstanding contracts may be the solution. The code needs updating, and updating to 5.4 would be useful, but short term everything needs testing and fixing for PHP5.3 :( This might be starting to become slightly off-topic for the list, but what prevents you from communicating the problem to your customers and also offering them the help they need? The whole reason that ISP's are currently moving from PHP5.2 to PHP5.3 rather than PHP5.4 is that there is a better chance that their client sites will continue to work. I can not say that for the ISPs I use and I've been talking to. For the handmade ones it's more what their distro offers, for the commercially professional ones it's more what their users ask for. http://w3techs.com/technologies/history_details/pl-php/5 use of PHP5.1 is slowing faster than 5.4 use is growing. I must admit I lack of skill reading statistics, however, I don't understand why you talk about PHP 5.1 while your problem is that some contracted services of your customers is changing to PHP 5.3 from 5.2. If you need a helping hand in porting legacy 5.2 code to 5.3, feel free to contact me. -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
http://w3techs.com/**technologies/history_details/**pl-php/5http://w3techs.com/technologies/history_details/pl-php/5use of PHP5.1 is slowing faster than 5.4 use is growing. This is wrong. At May 2012: PHP 5.1 starts with 4.9% PHP 5.4 start with 0.1 % In Februar 2013: PHP 5.1 has now 3.2% = lose of 1.7% PHP 5.4 has now 2.2% = grow of 2.1%
Re: [PHP-DEV] SplFileObject::__toString potentially returns false
- Ursprüngliche Message - Von: Charles Sprayberry cspray@gmail.com An: internals@lists.php.net internals@lists.php.net CC: Gesendet: 1:56 Dienstag, 5.Februar 2013 Betreff: [PHP-DEV] SplFileObject::__toString potentially returns false T here was a previous discussion on the return value of SplFileObject::__toString being an alias to SplFileObject::current() but that was about the design decision why and not really suggesting any kind of change or a technical error. In the discussion it was established that: (1) Changing this would be a BC break (2) It isn't really a bug in the codebase, the docs were just wrong The current implementation has a bug in that current() can potentially return false, if false is returned from the __toString() magic method a catchable fatal error occurs. [...] I would say that SplFileObject:__toString() being an alias to SplFileObject::current() makes the use cases for the method very limited and that the current implementation is mistaken in returning current(). I can think of no use case where SplFileObject::__toString() should return this value. If need to get the current line you're probably iterating and in that case should be using foreach() and don't really need to manually take care of that. Even if there is a use case for manually invoking `SplFileObject::current()` you probably aren't casting a string in that situation and a more expressive method call is better. (1) Leave the implementation the way it is and simply return a blank string when current() would return false (2) Change the implementation to return SplFileInfo::__toString() (3) Change the implementation to return entire file contents (4) Return some other unthought of string but remains consistent and logical I am personally partial to (2) or (3) perhaps in 5.5 but (1) could probably happen sooner? Thoughts? I often use this object. A few things I can notice: - In practice I never ran over this error. Mainly because I use `foreach` rather than the object itself in string context to obtain the line(s). - Even I did not run into a concrete problem, I would consider this a bug because the object itself is violating the __toString() interface. When I get that error with my own code, I always consider this a bug and fix it. So this should be fixed in PHP core code when I keep myself as a mark. - Because SplFileObject is a subtype of SplFileInfo, it should return the same for the same interface, e.g. `__toString()` must return the same type of value as of SplFileInfo to not break the substitution. Only the more specific parts of the interface are allowed to offer more specific behavior. Right now it violates LSP. This should be addressed and fixed behaving exactly like SplFileInfo. IMHO fixing all these flaws require a BC break which I would consider something good in this specific case. So I welcome a BC break as soon as possible so that in the future functions accepting a SplFileInfo also work with SplFileObjects if they make use of the string context. Until then, a workaround is to provide your own subclass of SplFileObject that overwrites `__toString()` again. Maybe this is something useful for projects that make use of the SplFileObject already. -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] (non)growing memory while creating anoymous functions via eval()
On 04/02/13 10:57, Ángel González wrote:
snip
The memory will stop growing (on my machine) at ~2491584 bytes and the
loop is able to run forever,
creating each eval() furthermore uniqe ano-function's but not
endless-filling Zend-internal tables.
but this still leaves the function record itself in the
function_table hash so with a non-zero reference count and this
doesn't get DTORed until request shutdown
Not familar with the Zend-internals but just about so i was imaging
and expecting it.
That why i [still] also confused/wondering why in the 2nd example the
memory will not grow *endless*.
It seems that the function records in the function_table will be
DTORed (or similar cleaned up) before request-shutdown at some point...
Could this be the case?
As you are reassigning $ano_fnc, the old closure is being destructed.
Had you used create_function(), it wouldn't happen.
Now the question is, if it is correctly freeing the functions (and it is
good that it does so), why is it not doing it when they have different
lengths?
It's a bug. The Closure class DTOR does not delete the derefenced
function from the CG(function_table).
If you did the eval at line 20 in say /tmp/xx.php then the
INCLUDE_OR_EVAL instruction calls the Zend compiler with the args:
(1) the source to be compiled and
(2) the title /tmp/x.php(20) : eval()'d code
The compiler than gives the closure function a magic name:
\0{closure}/tmp/x.php(20) : eval()'d code0x
where 0x is the hex address of the function substring in the
evaluated string. The compiler uses a zend_hash_update to insert this
into the CG(function_table).
What happens if you use a fixed length string replacing another string
of the same length dropping its refcount to 0 is that the allocator is
clever and will tend to reallocate the old one and hence the address of
the string is the same and the address of the offset of the function
substring is the same so it regenerates the same magic name -- pretty
much as an accidental side-effect. When this happens, it's this hash
update function that calls the DTOR on any pre-existing function with
this name.
I simply put a breakpoint on the relevant line in the
zend_do_begin_function_declaration() code and if you used a fixed offset
into the same string you only got one {closure} entry. If the
allocation ended up randomizing the address, then the {closure}
entries grew until memory exhaustion.
As I said -- interesting. Need to think about the consequences before I
submit a bugrep.
Regards
Terry
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
- Ursprüngliche Message - Von: Zeev Suraski z...@zend.com An: hakre hanskren...@yahoo.de CC: internals@lists.php.net Gesendet: 17:47 Mittwoch, 30.Januar 2013 Betreff: RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution * In that RFC you write: the integration won’t happen before late 2014. [if it's not bundled with PHP 5.5] Can you please outline why? Based on an 18 month release cycle, and assuming we release 5.5.0 in mid 2013, 5.6.0 will come out late 2014. I wonder where you pick those quantifications from, according to https://wiki.php.net/rfc/releaseprocess there is 12 month cycle/tact, and according to the release date of PHP 5.4 major releases (golden) are scheduled for the first of march each year (alphas accordingly earlier). * Which benefits does Zend Inc. see in contributing the Opcode cache? Simply put, this could benefit PHP greatly without negatively affecting our business in any way. And not simply put? * Last but not least, not related to the opcode cache alone, but related because you want to bundle it with core: If some day the PHP group decides to choose a similar software license, but different in the sense that it is more compatible with existing FLOSS licensing, would you have a problem to re-license as well, e.g. under MIT or Apache 2.0 for that part? The plan is to contribute the source code to the PHP project. It'll be under the same license as PHP and subject to any changes in the PHP licensing scheme that we'll agree on. Who is that we in the last sentence? Could copyright be transfered to the PHP group? Which developers so far did work on that code? Do we get the release history as well? -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Based on an 18 month release cycle, and assuming we release 5.5.0 in mid 2013, 5.6.0 will come out late 2014. I wonder where you pick those quantifications from, according to https://wiki.php.net/rfc/releaseprocess there is 12 month cycle/tact, and according to the release date of PHP 5.4 major releases (golden) are scheduled for the first of march each year (alphas accordingly earlier). I'm taking it from both reality and the discussions we had surrounding the release process RFC (in short, the 'yearly' in there was subject to change without notice; It's not an 11th commandment). I see good reasons not to go with a yearly release cycle, considering there's next to nobody actually interested in consuming those releases, but that's another story. * Which benefits does Zend Inc. see in contributing the Opcode cache? Simply put, this could benefit PHP greatly without negatively affecting our business in any way. And not simply put? Complexly put, this could benefit PHP greatly without negatively affecting our business in any way. I don't intend to become argumentative. You're obviously entitled to your opinion and I think that there's nothing I could say that would change it. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Martin Keckeis wrote: http://w3techs.com/__technologies/history_details/__pl-php/5 http://w3techs.com/technologies/history_details/pl-php/5 use of PHP5.1 is slowing faster than 5.4 use is growing. This is wrong. At May 2012: PHP 5.1 starts with 4.9% PHP 5.4 start with 0.1 % In Februar 2013: PHP 5.1 has now 3.2% = lose of 1.7% PHP 5.4 has now 2.2% = grow of 2.1% But PHP5.4 was released 1st March ;) So 5.6% rather than 4.9% and a loss of 2.4% I was just looking at the graph ;) Take up of 5.4 is having very little impact on the switch TO PHP5.3 is the point though. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Tue, Feb 5, 2013 at 1:42 PM, Lester Caine les...@lsces.co.uk wrote: hakre wrote: In reality we have to make choices where we DO spend time. There is still a mile of code out there being used live which is running perfectly on the PHP5.2 infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4 before we get around to 5.5. Why do you change the infrastructure if the code does not need it? I mean, provide the infrastructure the code needs and done. There is more than one vendor that offers support for PHP 5.2 infrastructure in the market. What's the deal? The point here is supporting customers that I've 'acquired' who are currently hosted on services that control that infrastructure. The long term aim is to move them to servers under our control, but in the meantime until contracts run out we have to live with such activity as 'We will be updating to PHP5.3 on the 1st April'. The problem now is how to deal with that situation, and paying up outstanding contracts may be the solution. The code needs updating, and updating to 5.4 would be useful, but short term everything needs testing and fixing for PHP5.3 :( The whole reason that ISP's are currently moving from PHP5.2 to PHP5.3 rather than PHP5.4 is that there is a better chance that their client sites will continue to work. http://w3techs.com/technologies/history_details/pl-php/5 use of PHP5.1 is slowing faster than 5.4 use is growing. If you do commercial support for customers and do not control the environment and/or use shared hosting, then something is totally wrong in your business model. It is also really off topic, in this mailing list or in this discussion. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Pierre Joye wrote: If you do commercial support for customers and do not control the environment and/or use shared hosting, then something is totally wrong in your business model. It is also really off topic, in this mailing list or in this discussion. It is totally on topic! The REASON I have gained this particular additional customer base is because they are all having problems with keeping their sites active! I had hoped to be producing a better set of documentation to help these type of users to cope with the 'BC compatibility' problems they are currently fighting, but there is nothing consistent to document. There are as many problems as customers with several years of legacy code written by different programmers :( THEY are not programmers ... I hope that as some point there will be some REAL support for stopping 'developing' PHP5 and move all of the new 'features' being discussed into a nice cleanly isolated PHP6 development stream. Then we can start documenting what IS being removed and stop trying to track which legacy feature needs to be re-worked rather than simply burying heads in sand and hiding them!!! My current roadmap is based on PHP5.4 servers with nothing hidden and eventually all of the code will be moved forward to that base, but I simply can't justify charging some customers for all the time this takes because they HAVE working sites currently and this is not giving them any return. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Tue, Feb 5, 2013 at 5:21 PM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: If you do commercial support for customers and do not control the environment and/or use shared hosting, then something is totally wrong in your business model. It is also really off topic, in this mailing list or in this discussion. It is totally on topic! The REASON I have gained this particular additional customer base is because they are all having problems with keeping their sites active! I had hoped to be producing a better set of documentation to help these type of users to cope with the 'BC compatibility' problems they are currently fighting, but there is nothing consistent to document. There are as many problems as customers with several years of legacy code written by different programmers :( THEY are not programmers ... I hope that as some point there will be some REAL support for stopping 'developing' PHP5 and move all of the new 'features' being discussed into a nice cleanly isolated PHP6 development stream. Then we can start documenting what IS being removed and stop trying to track which legacy feature needs to be re-worked rather than simply burying heads in sand and hiding them!!! My current roadmap is based on PHP5.4 servers with nothing hidden and eventually all of the code will be moved forward to that base, but I simply can't justify charging some customers for all the time this takes because they HAVE working sites currently and this is not giving them any return. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I hope that as some point there will be some REAL support for stopping 'developing' PHP5 and move all of the new 'features' being discussed into a nice cleanly isolated PHP6 development stream. Just see it as a car: you can drive it 10 years or longer, but from time to time you need new tires or repair some stuff. Regards, Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
hi, On Tue, Feb 5, 2013 at 5:21 PM, Lester Caine les...@lsces.co.uk wrote: It is totally on topic! no, really not. :( THEY are not programmers ... But you are. Evolution of the platform as a whole is part of the support, if desired and necessary. My current roadmap is based on PHP5.4 servers with nothing hidden and eventually all of the code will be moved forward to that base, but I simply can't justify charging some customers for all the time this takes because they HAVE working sites currently and this is not giving them any return. And the working sites will still work later as well if they don't change the platform. However porting applications to supported platforms is part of a support contract, and costs should or can be described. It is even easier now that we have a fixed life cycle (three years). But again, how one should do support or define the needs of his customers so they won't be in trouble (and himself neither) is not a topic for this list. cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] operator-0.3 extension update
Hi, thank you for pointing me in this direction. The opengrok program is awesome! And I managed to update the operator-0.3 extension to work with php 5.3 (will be working on making it compatible with 5.4 next). I was wondering whether (where) I should submit the code so that the package can be updated, and whether there are issues with supporting operator overloading that make it something that you will not want to support too much. Best regards, Gabriel On Sun, Feb 3, 2013 at 1:22 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, Feb 2, 2013 at 3:32 PM, Gabriel Wu gabrielw...@gmail.com wrote: Dear all, I am looking for the place to get support for writing a php extension. Just wondering if this is the right place. I am looking to create a custom class where I can overload the operators of the class. I have found an old extension called operator-0.3 authored by Sara Golemon poll...@php.net, whom I noticed is CC'ed in the messages here. I just looked over her code, and was trying to make sense of it, but as it stands, I found a dearth of documentation on overloading php class operations. Is this the right place to ask for help for zend interfaces such as php_operator_zval_ptr, etc? Thanks in advance for your help! Gabriel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi, we have a bunch of information/docs/examples here and there, check out the links at http://pecl.php.net/support.php#resources and using http://lxr.php.net/ is also helps a lot for wading through the php sourcecode. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
